proposal (Thomas Kalka), first called WikiProxy, then renamed to DataServer. A good name ist still missing (see below).
A DataServer (or however to call this service) provides storage and name services for pages and all other data used by a special wiki or other data-frontends. It may acts as as “relay” for other DataServers?, providing caching and synchronisation for data owned by them.
A Wiki may be tought as a DataServer together with a TranslationEngine? and a SyndicationEngine?.
Implementing the “storage and retrieve - part” of a Wiki into a stand alone application enables the shift of the presentation layer into the client (browser), as suggested on CommunityProgrammableWiki .
Proposal for an implementation
- SID: its own name, a big prime (public key)
- SKEY: its own key, a big prim (private key)
- versions: a version is a piece of data, known by its MD5 hash (VID)
- ideas: an idea is know by the VID of the first version creating the idea (ID)
- names: a page may have as much names as she wants, NAME* → ID
- metadata for pages:
- at least
- home-location (WikiID?)
- publishing time
- predecessors (VIDs), enabling version controll
- exactly one idea (ID)
- UP: broader ideas (IDs), enabling hierarchies
- IS: kind of (IDs), enabling different page-types (image, forms, comments etc)
- T: tags or topics (IDs)
- N: names (STRINGs)
- other Relations: (ID,ID)+ , enabling RDF-Queries
- consensus: the chain-path of predecessors of an idea lead to one page
- store page (content,metadata)
- retrieve page by SID,VID: returns exactly this page, if available
- retrieve page by SID,ID: returns page if consensus, otherwise VIDs and Metadata of version-tree-endnodes
- find page by Name (local and global): returns lists of IDs matchting the name
- register listener: a foreign WikiProxy asks this proxy to be provided with updates of pages for specific IDs or topics
- receive update: take a bag (zip) with pages from a foreign proxy, this proxy has registered to or remote stored pages which have been updated. the bag is crypted with own WikiKey?. Wether WikiProxies? automatically update pages from update requests or put them to a moderation queue is the WikiProxy owners decision.
- propagate foreign pages to their homes, forwared pages are crypted with the WikiID?
- get foreign pages as requested and cache localy
- InterWikiGateway? – BayleShanks’ software that can serve as a posting and reading proxy to other wiki engines
- File Systems
Some questions, to help skin out the idea:
- The DataServer stores pages on it’s own?
- The DataServer reads changes on other wiki, and replicate them locally?
- The DataServer writes changes out to other wiki?
- If the data is edited, what happens? Do the changes go to the other wiki, too?
- When you say “translation,” are you talking about human language translation, or machine-machine protocol translation?
- What kind of metadata are you interested in?
I tried to answer above. Delete questions which you find answered. This all seems to me like the definition for a file system. So there should be already some similar work. DataServer may additionaly be implemented as a WebDavServer? also, providing this functionality. Please correct my poor english were appropriate, enabling me to learn to do it better
The new version control system for the linux kernel source looks similar to this proposal also.
I’m overwhelmed by the specificness. It started out really really general, and then became …. ….whooosh!… Super-specific!
Okay, well.. Uhm…
What does it mean: “a page is known by its rs5” ..?
I mean, the pages are changing all of the time, if it’s a wiki, right?
I’m not sure I get the vision, amidst all the details.
Ok. Some confusion is due to terminology.
What I called “page” above is a specific page-version in an normal wiki. A better name is maybe “version”. I changed the proposal to this name.
What I call “idea” is a page in an noraml wiki. I drop the idea of having OneName? for a page, thus calling it “idea”. If the name may vary and this thing might have many names the only coherence is that it declares itself as a successor to a specific “version”.
It is, by design, not possible to change “versions”.
Btw, jut read ModularWiki. Its the same idea with a different implementation ambition.
Thinking about the main questions:
- what is the name of a data-entry ?
- how should data be tagged ?
The idea behind DataServer is:
- name is given by reference to a idea
- tagging connects ideas
- “human names” may change from context to context
- how does WebDav deal with Names, Versions, Tags ?
Wondering, why this pages is displayed in a PageCluster in RecentChanges. How do I switch this ?
I suspect that this page may be a small (visible) part of a (very large) iceberg, if only because it triggers more thoughts that I can make quick notes about, in spite of my belief that this is probably going to be relatively large (and important).
For the moment, I am simply going to add a few additional points …
- In some cases, a design that separates the Data storage considerations and Name considerations may be important (e.g. optimizing the use of LocalNames with respect to the need for a unique Key within the data store, genereally affects the need for Aliases and some other types of MetaData).
- Software designs and functions will be quite different if …
- a TiddlyWiki (one type of Client Side “serrver”) is used to create a Tiddler that merely GETs a block of text from a DataServer. In this case, all the server may need to do is send me the block of text associated with a Key, since I will already have effectively assigned my own LocalName.
- Such a block of text could exist in the data store as either wikiMarkup or as the corresponding rendered HTML, since both the DataServer and the Client-Side Server (a DisplayServer?(?) acting as a Browser pre-processor?) could render the markup.
- The type and level of TransClusion that is supported, will also have a significant impact on the software’s capabilities.
- One of TiddlyWiki’s fundamental design assumptions is MicroContent, a concept which seems to allow for very small snippets of text to be included in very deep nests. In the contexts of a DataServer, it will be necessary to consider the relative efficiencies of storing each block of MicroContent that may be part of a nested TransClusion as a separate block, referenced by its Key (or PurpleNumber) or, alternatively storing a composite block made up of the nested, pre-assembled component blocks.
- A great deal of insight into the relative merits of these approachs can be derived from considering either
- “spidering” an html page, taken to the extreme of creating a single ‘infinite’ page, versus
- giving the viewer the ability to resolve each and every hyperlink within a current Browser window, while maintaining both a local static menu and a BreadCrumb? navigation trail.
It seems to me there are many threads of thought that are knotted together here and that it may take quite some time to reconsider the obvious individual components of a WikiEngine, based on their basic functions.
I do think its important to try to understand these ideas so that we will have a better appreciation of what we currently have and what we could create.
Then, it will take even longer to recast these deliberations into working software that can be subjected to the test of use by a real community.
As opposed to a ProxyWiki?, which is what I’m renaming the WikiWindow idea after Lion thought of the term
Is a WikiProxy essentially a StandalonePageDatabase?, with an eye towards synchronization and distributed wikis? If so, may I suggest that term instead?
Yes. PageDatabase is a better name. I would ommit “standalone” (its standalone or distributed).
But PageDatabase is a term in meatball already.
Lets take DataServer for the moment.
I don’t have any strong opinions on this but you might want to consider …
- DataServer is an existing term that is quite well defined and will tend to confuse those have already encountered it.
- PageServer? is (in my experience) less commonly entrenched.
- PageSource? is not in use and may even be more descriptive of the concept.
WikiSphereServer?. After all, “we’ve taken the mandate” to build the WikiSphere?, a layer of the NooSphere.
To enhance confusion a moved the content back to this page. I do not understand why it was just shown in a ThomasKalka-Cluster. Sorry.
The name is not very important to me. I would like to discuss wich basic set of operations such a server has to implement.
It’s impossible to plan this. One has to do this and let it grow according to the real needs of wiki communities.