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?
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
Carl Youngblood wrote:
...
.
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.
I have local Ruby wiki that calls out to CVS to sync various home PCs. Page fetches, edits, etc. trigger a call to cvs for add, commit, update, and so on.
It's not terribly efficient, and I need to do periodic manual checks for merge conflicts, but I haven't really put much effort into it. It's Good Enough, and lets me use my wiki as thought organizer, address book, bug tracker, and so on, across multiple household PCs and laptops.
James
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.
Carl
···
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).
Carl Youngblood wrote:
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
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.
So is rendezvous a completely open source technology? I thought it was
part of Apple’s proprietary offerings.
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?
My guess is that the best thing to do would be to ask the user on a case
by case basis when another user’s repository became available whether he
would like to merge in its changes or not. As long as there were no
conflicts, all the differences between a user’s repository and every
other user’s could be merged together. When conflicts occurred, the
system would default to asking the user whose portion has precedence, or
he could even specify a consistent version to which precedence should be
given. There are probably a lot more caveats to deal with, but I
believe it could be done rather successfully. Though these cases would
have to be taken care of, what I think would be by far the most
important use case to support is when a single user updates the wiki on
different machines that are intermittently off-network and wants to make
sure they stay in sync with each other.
Carl
if you look on the subethaedit website you’ll find reference to papers
about multiple synchronous editing, that may be of interest to you.
···
il Wed, 2 Jun 2004 09:32:51 +0900, Ben Giddings bg-rubytalk@infofiend.com ha scritto::
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?
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.
···
Le 1 juin 04, à 22:41, Carl Youngblood a écrit :
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.
So is rendezvous a completely open source technology? I thought it
was part of Apple’s proprietary offerings.