UneGrandeSoupe

Cette page a démarré sur OneBigSoup

Sur CommunityWiki, nous ne courons plus après l’InterWiki comme la solution ultime pour faire réseauter les wikis. Mais nous croyons plutôt en des MoteurWiki réseautant avec tous les LogicielsRelationnels de façon à ce que le wiki, avec tous ses avantages inhérents pour gérer du texte collectif semi-stable, puisse remplacer les paradigmes moins efficaces de gestion de contenu.

Le jour où tous les logiciels de communication (voir notamment et mettre à jour LogicielRelationnel) seront intégrés, nous baptiserons l’ensemble résultant : “UneGrandeSoupe.”

La Recette

Quelques ingrédients basiques :

Une brève explication de chaque idée.

Serveur Personnel

Un serveur personnel est comme un ServeurPersonnelDeLog, avec de l’information complémentaire sur vous. Il stocke de l’information attachée à votre personne. Par exemple, il dispose de votre nom, de votre adresse email, de votre clé PGP publique, de votre adresse web, de votre adresse de blog, des liens vers vos amis, des liens vers vos différentes ressources vous concernant. Il dispose d’un ServeurPersonnelDeLog construit à l’intérieur de telle façon à ce que quand vous postez quelque part, ce quelque part puisse automatiquement laisser une note sur votre serveur personnel de log. Quand vous conversez par messagerie instantanée ou IRC ou quoi que ce soit et que vous n’êtes pas en mode secret, il laisse alors de petites notes à propos de vos activités en ligne. Si quelqu’un commente quelque chose que vous avez écrit, vous obtenez de petites notices dans votre log personnel. C’est tout ça.

Ainsi c’est “vous”- ou plus précisément, votre corps en ligne.

Imaginez que nous ayons un grand serveur quelque part, détenant à l’intérieur 100 de ces morceaux d’information de personnes. C’est un “serveur personnel.” Vous pourriez dire qu’il stocke les corps des personnes.

Quand vous vous connectez sur n’importe quel forum, vous devez juste pointer votre serveur personnel et lui dire “Hé ! C’est moi !” Et il peut vous croire, ou peut vous demander un mot de passe pour vérifier, on peut vous demander “merci de crypter ceci avec votre clé” et puis la vérifier et ainsi de suite. Ce sera fonction du niveau de confidentialité désiré pour savoir si c’est bien vous. Et ainsi de suite.

Ainsi voilà le véhicule pour votre corps en ligne.

Serveurs Locaux de Nom

C’est là où nous stockons les noms pertinents pour les choses. J’ai décrit cela ailleurs sur IntComm:LocalNames. Pas un très bon lien, parce qu’il pointe vers une page d’un WikiScratch, mais il restera là pour le moment. Si quelqu’un veut écrire à nouveau ce paragraphe, expliquant les noms locaux, sentez-vous à l’aise pour le faire.

Un Serveur Local de Nom cartographie un bouquet de raccourcis de noms comme les WikiNoms vers des URL pleines, de telle façon qu’on peut saisir DannysBlog? au lieu de http://dannyayers.com/.

Cela fait gagner du temps de saisie et du temps de lecture et permet à quiconque de construire un LangageDeFormes de bonnes pages, et si quelque URI change, le nom raccourci peut rester le même. Attaché à un wiki, il agit plutôt comme une redirection d’un bouquet de pages Wiki vers des sites externes.

La où le Serveur Personnel isole vos informations en ligne personnelles et vos activités du wiki (et de toute autre communauté en ligne), le serveur local de noms vous isole ainsi que vos “liens et langage” de groupewiki.

Il facilite les renvois vers des choses au-dessus des pages wiki. Vous pouvez maintenant vous exprimer à propos de blogs, des conversations en mode fil, d’images, de pages web statiques et de “tout ce qui peut être pointé, et ce en toute ubiquité. Vous n’êtes pas confiné à parler de wiki, de parler de “choses” dans ce wiki (ou sur un wiki proche, ou un wiki éloigné - fourni parce que vous avez l’InterLien). Vous pouvez parler de tout, n’importe où avec la facilité des noms locaux.

Nous n’avons pas simplement isolé l’information utilisateur (votre corps en ligne) mais nous avons aussi isolé les noms et les relations nom-lien.

Serveurs de Groupes

Pour notre prochain truc, nous extrairons les Modifications Récentes hors du wiki.

C’est une étape facile, parce que c’est simplement une agrégation RSS. Mais nous allons là rendre un peu plus intéressante.

Nous allons suggérer que les nouveaux-venus dans le groupe puissent ajouter leurs propres fils RSS. Ils disent simplement, “Bonjour, je suis un nouveau-venu. Voilà mon fil RSS.” Nous supposons la bonne foi [1], mais s’ils sont là simplement pour pester contre nous ou nous vendre du viagra, nous pouvons les sarcler ou imaginer quelque chose d’équivalent s’ils sont dans leur période probatoire. Je ne sais pas exactement comment cela fonctionnera mais je suppose que nous aurons là quelque chose.

Imaginez que ces Modifications Récentes sont comme la section soucoupe de l’Entreprise. Vous savez qu’elle peut se détacher – vous me suivez ? Dans Star Trek : La Prochaine Génération ? Oui : la section soucoupe peut se détacher et voler de ses propres ailes. C’est ce que nous faisons ici avec Modifications Récentes.

Imaginez que les Modifications Récentes de votre wiki soient maintenant détachées, mais que le groupe de personnes qui inter-agissaient sur le wiki et se liaient d’amitié autour des Modifications Récentes est en train maintenant de flotter au loin dans les Modifications Récentes.

A ce stade, ils ne sont simplement pas en train d’observer leur wiki, mais ils observent tout aussi bien les autres choses.

Nous pouvons appeler ce Modifications Récentes détaché et étendu – nous pouvons appeler cette chose : un “Serveur de Groupe.”

Les personnes peuvent pointer à l’intérieur, par exemple pointer le fil RSS d’un blog d’un membre de leurs cliques vers ce serveur de groupe. Elles peuvent observer de multiples fils RSS de wiki. Elles peuvent suggérer des liens à leur pairs comme sur WikiFeatures:RaisedChanges.

Je ne connais pas les conditions particulières : Peut-être que les résumés agrégés des blogs de tous les membres du groupe rassemblés apparaissent tous dans une page visible (comme la page des journaux intimes de KuroShin) et peut-être d’autres choses sur l’agrégation : Que font les membres du groupe ? que se passe t’il sur les pages, quels sont les liens suggérés à regarder, les happenings sur les serveurs locaux de nom du groupe – peut-être tout cela se déroule t’il sur une page séparée ?

Sans nous soucier, nous disposons là d’un SystèmeDeConsciencePartagée. Mais vous ne “postez” pas vraiment sur le système. A la place vous postez sur cette chose en postant quelque part ailleurs.

Par exemple, si vous postez sur un fil de discussion quelque part, et que vous fassiez une telle opération en tant que membre de ce groupe, alors le groupe le verra sur son radar. Si vous postez sur une page d’un wiki que le groupe observe, alors votre billet apparaîtra sur le radar du groupe. Si vous postez sur une entrée de blog que le groupe surveille, ceci apparaîtra sur la page d’observation du blog collectif du groupe.

Ainsi, cette idée quelque peu embrouillée est un “serveur de groupe.”

:Vous pourriez faire un serveur de groupe sans “détacher” les Modifications Récentes en utilisant les FaisceauxUnifiés. Cela prendra n’importe quel fil RSS et prétendra que c’est un élément d’un Faisceau. Cela semble produire ce que vous décrivez et ce n’est pas brouillé  “

Pour finir :

Document, Fil de Discussion et Serveurs de Blog

Prenez le wiki comme exemple.

Nous avons dépouillé le wiki de ses utilisateurs avec le serveur utilisateur. Nous avons dépouillé wiki de ses Modifications Récentes avec le serveur de groupe. Nous avons même dépouillé wiki de ses noms de pages en ayant le serveur local de nom.

Qu’est-ce qu’un Wiki ?!

Wiki est “simplement un serveur de document.” Il est simplement une chose qui stocke et vous laisse éditer les documents. Probablement, il se contente de les numéroter. Vous ne remarquez jamais cela, parce que vous utilisez tout le temps les noms en local.

Regardons comme cela fonctionne. Vous êtes sur Internet.

Vous êtes vous : vous avez votre serveur personnel avec lequel vous êtes relié.

Vous assumez le rôle d’un membre de groupe : vous postez sur votre “suite de groupe” et même probablement plusieurs billets en une seule fois.

Vous allez vers une des pages en saisissant à l’intérieur de votre navigateur web un nom local. Vous dites, “UneGrandeSoupe”, et Mozilla (ou que sais-je ?) regarde ce nom dans le cache de votre serveur local de nom et vous dit : “Ah, oui, http://www.emacswiki.org/cgi-bin/community?00003591” et vous y emmène. Vous ne savez pas que cela vous conduit vers #3591 et ne vous en souciez pas. En ce qui vous concerne, c’est simplement “Une Grande Soupe.”

Vous éditez la page et le serveur de document reconnaissant tant vos noms personnels pour les choses et vos noms de groupes pour les choses, relie correctement tous les liens.

Vous pressez la touche sauvegarder et cela vous renvoie des notices vers vos logs personnels (ceux qui observent la page) et vers les logs des autres observateurs.

A ce stade : je ne suis pas en train de dire que voilà à quoi ça va ressembler. Ce sera probablement très différent, avec des différences majeures.

Cependant, je me dis : Les choses fonctionneront un peu comme ça. (Je présenterai la trivialité de cette solution dans un moment.)

Mais à ce stade vous pouvez constater que nous ne sommes pas contraints à faire simplement du wiki.

Des Fils de Discussions. Vous pouvez avoir des serveurs de fils de discussion. Si vous êtes sur le site web de votre groupe et vous dites “Produisons un nouveau fil de discussion,” on vous demandera le nom local du fil que vous créez et puis cela ira vers le serveur du fil de discussion, et cela “vérifiera un fil.” Supposez qu’il obtienne le fil de discussion #5349. Il lie le nom que vous avez donné pour cette discussion à l’URL de discussion #5349 et après vous partez. Vous disposez maintenant d’un fil de discussion que vous pouvez pointer simplement de n’importe où.

Ou des images. Si vous téléversez une ressource image, vous irez vers un processus équivalent.

Ou des blogs. Si vous voulez produire un nouveau blog, vous pouvez vous diriger vers le serveur de blog, à la main, et demander pour un blog # (“Vous avez été classé blog#4354.”) ou la machine peut le faire automatiquement – vous allez vers votre page de groupe et dites, “J’aimerais vérifier un blog, à mon nom, pour une présentation que ce site de groupe que j’appellerai ‘Le Carnet de Développement de Lion’” et le serveur de groupe remplira tous les papiers nécessaires à votre place.

Et ainsi de suite. Les choses auxquelles nous n’avons pas encore pensées à présent. “Les serveurs de code.” Que sais-je. Tout ce que vous voulez.

Cela verrouille tout à l’intérieur des architectures de “groupes,” “individus,” et “noms”, et tout ce dont on peut parler d’autre.

D’où le terme, “Une Grande Soupe.”

Évidence

Pourquoi penser que nous allons faire ainsi ?

Parce que :

Les personnes quittent les journaux personnels de KuroShin pour partir créer leurs propres blogs, et leurs propres fils RSS. Les personnes cherchent des technologies pour produire facilement des fils de conversations à travers internet. L’idée de fils portables de conversations est en train d’émerger.

Ces technologies démarrent toutes comme des expériences sur des serveurs centralisés, mais finiront pas s’évader ailleurs. De ce fait, les personnes peuvent avoir de l’indépendance et faire des choses comme elles l’entendent, expérimenter de nouvelles technologies et développer de nouvelles choses sans être liées à un serveur particulier, à un individu particulier ou à une communauté particulière.

Parce que :

Considérez que nous ressentons déjà la pression pour implémenter la ConstructionDeFilDeDiscussion? dans wiki. Je pense que nous savons tous que c’est plus ou moins une bonne idée ; nous sommes simplement lassés de la FonctionnalitéKarma1. Et c’est vrai nous devrions l’être. Que faisons-nous en tant que programmeurs quand nous sentons que nous mettons trop de technologies à un seul endroit ? Bien, nous essayons de démembrer les choses. Ce qui est exactement ce dont je parle : un démembrage massif.

Ayant pensé à ce modèle en ce sens, il devient clair dans mon esprit que le wiki “devrait” aussi supporter les blogs. Pas simplement des pages que nous gardons pour mettre nos blogs dessus, mais de véritables blogs. Celui où vous pouvez simplement saisir à la volée. Disposer de résumés qui sont ensuite agrégés dans un central “Voilà l’agrégateur des blogs de CommunityWiki,” collectant tous nos carnets web de CommunityWiki assemblés à l’intérieur.

“Mais nous pouvons déjà faire cela sur CommunityWiki,” Je vous entends pleurer. Oui, nous pouvons. Mais, non, ce n’est pas suffisant malgré tout. Même remarque que pour la ConstructionDeFilsDeDiscussion?. Nous ne voulons pas être obligés d’éditer une page entière, juste pour ajouter un billet. Nous ne voulons pas de techniques à la noix et de bidouillages. Nous ne voulons pas saisir [[new?]]. Nous voulons simplement cliquer sur “Ajouter Un Billet,” saisir un résumé dans la boîte résumé, saisir un billet complet dans la boîte billet complet et disposer de cela vers une section spéciale “Voilà les CarnetWeb” et que ça fonctionne comme ça. Je sais que nous pouvons simuler tout cela en utilisant de pures pages wikis, mais simplement le fait de dire nous pouvons ne signifie pas que c’est le meilleur. Et que c’est cela que nous voulons réaliser.

Nous pouvons simuler toutes les fonctionnalités des formats de discussions de K5 ou de Slashdot. Mais ce n’est pas ce que nous voulons vraiment. (A nouveau, nous ne voulons pas être contraints par les fils de discussions de K5 et de Slashdot – nous aimerions être aussi en mesure de gommer les discussions. Dans la plupart des cas.)

Aussi mes points sont :

La conclusion logique de ces deux forces est que : Nous mettrons plus à l’intérieur d’un wiki. Et ensuite cela explosera à l’extérieur. L’architecture que j’ai décrite comme “Une Grande Soupe” est une architecture explosée.

Pourquoi C'est Cool ?

Une fois que les choses ont explosé, elles deviennent nettement plus… Ouvertes. Spacieuses. Et même “Soupeuses.”

Quand vous êtes verrouillé à l’intérieur de LiveJournal, vous êtes bloqué à l’intérieur de LiveJournal. Vous pouvez seulement jouer avec les liens avec vos amis de LiveJournal.

Quand vous êtres verrouillé à l’intérieur de KuroShin, vous êtes bloqués chez KuroShin. Vous ne pouvez faire la publicité de vos fils RSS non existants pour votre journal K5. Vous ne pouvez pas agréger des personnes non membres de K5 dans votre liste d’observation. Vous êtes englués avec les personnes de K5.

Mais une fois que les choses explosent, il y a vraiiiiiiiiiment une plus vaste communauté, avec beaucoup plus à faire dedans et beaucoup plus de choix et beaucoup plus de diversité et beaucoup plus d’expérimentations, que ne pouvait fournir la CommunautéMurée.

Développement

L’idée d’une architecture distribuée de web services / Internet n’est pas nouvelle. Les personnes en ont déjà beaucoup parlé (comme sur IntComm:EventServer?), probablement en retournant vers DougEngelbart et TedNelson.

La phrase “UneGrandeSoupe” doit identifier une dispersion des personnes et une stratégie particulière d’approche pour construire The UneGrandeSoupe. Il existe d’autres groupes. #esp en particulier - (http://webirc.espnow.net/) a mené une vision similaire appelée “plex.” (voir WeAreNotAlone.)

L’effort de “UneGrandeSoupe” est largement basé sur “IntComm” - le wiki scratch des Communications de l’Internet Public.

En termes d’IRC, on en discute sur #wiki et #esp (en connexion avec l’effort de Plex.)

En termes de wiki, c’est discuté sur IntComm, parfois sur InterWiki.

Les différences entre Plex et UneGrandeSoupe ont plus à voir avec lapproche de construire plus ou moins la même chose.

Plex se concentre sur la distribution. Plex a cinq sections-clés : Une networking API, un système pour distribuer les fichiers sur de multiples serveurs similaire à FreeNet, des “Index” qui sont des sortes de IntComm:PropertyServer?, un serveur d’Identité et un système pour la publication (et peut-être la distribution) de services. Pour en savoir plus sur le système lisez en anglais some architecture notes.

UneGrandeSoupe n’est pas tant de la distribution que de la division de responsabilités parmi les serveurs. IntComm:OneBigSoup comprend des idées comme le IntComm:PersonalServer? (similaire mais différent du Serveur d’Identité, un IntComm:GroupServer, IntComm:LocalNameServer?, IntComm:DocumentServer, IntComm:BlogServer? et IntComm:ThreadServer. De nouveaux contenus sont découverts comme un IntComm:EventServer? sans oublier le IntComm:PropertyServer?.

Ces systèmes sont véritablement très similaires et peuvent fonctionner l’un avec l’autre. Aucune vision n’exclut la vision de l’autre. Ils fonctionnent plus ou moins vers le même objectif.

Où mettre ceci ?

Salut, c’est Escape (=NicolasMontessuit). Je me rends compte que ce serait bien de releaser le code de BlueMoon. À tous ceux qui m’en font la demande, j’installe un clone de BlueMoon sur leur serveur Apache clefs en main… E-mail: nicolasmontessuit@wanadoo.fr

Au cas (fort probable) où cette intervention tombe sur la mauvaise page, merci de me rediriger le texte là où il faut ! ;-)

LangueFrançaise PageTranslation OneBigSoup

Proposition traduite de LionKimbro sur OneBigSoup : seul lien de référence.

Discussion

[de] Zu wenige Köche verderben den Brei.
[en] Too few cooks spoil the porridge.
[fr] Trop peu de cuisines gâche le porridge

Bientôt UneGrandeTable pour poser la marmite. Mattis, tu viens m’aider à MettreLeCouvert? :)

Footnotes:

1. traduire FeatureKarma

Define external redirect: PersonalServer ConstructionDeFilDeDiscussion LocalNameServer EventServer MettreLeCouvert PropertyServer BlogServer ConstructionDeFilsDeDiscussion new DannysBlog

EditNearLinks: FreeNet NicolasMontessuit KuroShin CarnetWeb CommunautéMurée FeatureKarma MoteurWiki WikiNom SupposerBonneFoi TedNelson FonctionnalitéKarma LiveJournal DougEngelbart BlueMoon

Languages: