Distributed wiki idea (was blank--resending)

[Carl Youngblood]

For a while now I've been really excited about using wikis to store my
random thoughts and to collaborate with others. They have proved
somewhat useful, but I often have problems when I am in some place with
my laptop but no internet access. I could jot down my ideas in a text
file and save them in the wiki later when I get back on the internet,
but I would like to be able to still view the other pages in the wiki
when I'm offline, and I'd rather not have to explicitly export the wiki
contents every time I leave the net and import them every time I return
to it. So far I have found no practical way to do this.

What I'm picturing is a wiki where you have a local copy on your
machine that you can take with you that syncs back up with the online
version later. At merge time any conflicts would be resolved on an
individual basis.

Though I haven't used it, I'm told that this is the idea behind GNU
arch for source control. I want something similar for a wiki.
Basically like a distributed version of instiki.

Thoughts?

 

[David Heinemeier Hansson]

Though I haven't used it, I'm told that this is the idea behind GNU

arch for source control. I want something similar for a wiki.
Basically like a distributed version of instiki.

This has actually been a long time dream for Instiki right from the
get-go. My role model is SubEthaEdit (a collaborative editor for OS X)
that'll let each participant keep a copy of the shared document when
the "server" goes online. Once that happens, any of the other
participants can re-share the document and works continue on as if
nothing happened. A very resistant model.

The dream was to pair this with some native OS X technology in form of
Rendezvous. Imagine being at a conference. One guy starts a wiki to
collect notes. His machine is now the be all, end all of this
conferences notes. That's a big liability for the rest of the
attendents. His machine could go run out of battery, he could loose his
net connection. Or just take his toys and go home early.

Now, the dream continues, if other participants hooked on like in the
SubEthaEdit scenario, and shared the wiki with the server, there would
be a much more resiliant mesh. New pages and changes would get pushed
around all the participating wikis. They would automatically find each
other through Rendezvous and use a mutual observer-like (DRb?)
relationship to push and pull news.

I understand that this isn't quite what you're calling for, but perhaps
this observer-like relationship doesn't have to be synchronous or near
that. Perhaps it could be made to work very asynchronously, as in days
apart.

Anyway, these are my thoughts. Some work has already been done to
further this as I've build a OS X native version of Instiki
(double-clik and you're set!), which is scheduled to get Rendezvous
support in the most childish form (merely broadcasting a notice that a
webserver is running).
--
David Heinemeier Hansson,
http://www.instiki.org/ -- A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ -- Web-based Project Management
http://www.loudthinking.com/ -- Broadcasting Brain
http://www.nextangle.com/ -- Development & Consulting Services

 

[Ben Giddings]

Sounds cool, although one of the great things about instiki right now is
that it can be run on any platform that ruby can run on. It would be
great to have a distributed wiki that only required ruby. I, for one,
have a 12" iBook, a desktop running Windows XP and another PC running
Fedora linux. I would like to be able to use the wiki on any one of them.

Well there's nothing about rendezvous that's fundamentally tied to OS X.
(I know, having recently put it on an embedded Linux device), so this
shouldn't be a major stumbling block.

What I find interesting is that this sounds a lot like Lotus Notes. As
I understand it, it's simply a database that users have on their
machines, that every so often resynchs with a master server. They even
do email that way.

Now the p2p part could be interesting. How do you resolve conflicts
between versions? Do you rely on the timestamps of the peer machines,
even if they're not necessarily right? Do you treat one machine as
special, say the one that created the document initially, and make it
the server?

Ben

 

[Guillaume Marcais]

Le 1 juin 04, à 22:41, Carl Youngblood a écrit :

So is rendezvous a completely open source technology? I thought it
was part of Apple's proprietary offerings.

http://www.zeroconf.org/

That's one domain where Apple has been pretty smart lately, taking full
advantage of open standard and open source stuff (konqueror and Safari,
cups, etc.). They create fancy names (airport for Wifi, Rendez-Vous for
Zeroconf) to get recognition.
Mandrake 10.0 I believe has an implementation of ZeroConf.

Guillaume.

 

[gabriele renzi]

il Wed, 2 Jun 2004 09:32:51 +0900, Ben Giddings

Now the p2p part could be interesting. How do you resolve conflicts
between versions? Do you rely on the timestamps of the peer machines,
even if they're not necessarily right? Do you treat one machine as
special, say the one that created the document initially, and make it
the server?

if you look on the subethaedit website you'll find reference to papers
about multiple synchronous editing, that may be of interest to you.

 

[James Britt]

Carl Youngblood wrote:
...