[Wikireader] Quick intro re: offline viewing/editing

[Samuel Klein]

Bjoern,

Two-way synch is the most interesting focus.  read-only fails for most
users some of the time, and helps them forget the reflexive desire to
edit whenever you see something that needs changing. I find that edits
are most likely to be at hand and pressing when one is not online.

You have the right idea with aggressive diff3 synch, adding then
suppressing new changes if there's a conflict, and notifying users on
the target wiki.  This has been suggested for mikmik and a few other
synchronization projects -- some variation on the theme should work
for any wiki.

I would add
 * a low-impact option that doesn't post updates directly to a page if
there's any conflict, but instead posts the update to an
offline-editor namespace, including the revision ID of the original
point of fork (for 3-way diffing by a conflict-resolution client later
on) in the post.
 ** you can abuse the fact that the revision diff tool in mediawiki
doesn't care  if the revs compared are from the same article title or
ID or not.
 * notify a group of users via a special page that lists offline autosynch's
 * note in the edit summary of pasted changes when you're integrating
offline edits (include details such as who the offline editor[s]
appeared to be, how many revs are being updated)
 ** (medium) you need to pass on changes to version history, not just
the total diff; assuming that there can be any users editing wiki B as
well as wiki A
 *** (advanced) similarly, deleted pages and deleted revs need to be passed on
 * pass through/upload files in the same fashion
 ** (medium) support for interactive upload process, where you can
resolve conflicts without cluttering up the page history.


Warmly,
SJ


On Wed, Jul 8, 2009 at 6:17 PM, Bjoern Hassler<bjoern at caret.cam.ac.uk> wrote:
> Hi Samuel,
>
> sorry for the slow reply.  How about I just put forward some of thoughts,
> and you can let me know what matches with your or other people's interests?
>
> Basically, I'm interested in 'intermittent connectivity' scenarios. For
> example, a university in the developing world contributes to some open
> e-learning site (say wikieducator), then connection goes for a month,
> cutting them off from the resources they previously created. So that's not
> acceptable, and if we want poorly connected educational institutions to
> participate in 'OER' , we need to come up with better technologies.
>
> So to this end, I'm basically interested in 'moving content' around, whether
> that's for wiki synchronisation, or whether that's for reformatting content
> into various forms desired by the end user. I'm interested in text, but also
> in more complex content, such as video/audio and learning objects. Another
> question is why isn't wiki editing more like svn? If your commit doesn't
> conflict, then it should be accepted. If there are conflicts, you need to
> resolve conflicts.
>
> There's of course scope for new wiki systems that handle all of this
> beautifully - but I prefer pragmatic solutions. Many people use mediawiki,
> and there already is a lot of content in mediawiki.
>
> So what can be done in mediawiki? Firstly, I think there should be simpler
> ways to do one-way mirroring. This is relatively straight forward, and would
> be really a good step in the right direction. It means that you can't edit
> when you haven't got connectivity, but for "most users most of the time"
> that's ok.
>
> Of course some attempt at two-way synchronisation would be good, and I've
> got a writeup of some of my experiments here:
> http://www.sciencemedianetwork.org/wiki/Mediawiki/OAI_mirror/pragmatic_synchronisation
>
> It basically uses the mediawiki OAI extension to move content from wiki A ->
> B. You can make changes to B as well, and these get moved upstream to A
> prior to synchronisation. Conflicts are resolved manually. It's all very
> hacked together, as a proof of concept, and one could easily do this in much
> better ways.  I would really like to get some people together to look at
> this properly, so that it becomes more of a production ready solution. I
> would be really happy to help with the discussion and coordiation, but these
> days don't really have time to do any serious programming myself :-)
>
> Looking forward to hearing about your use cases and solutions!
>
> All the best,
> Bjoern
>
> On 1 Jul 2009, at 20:07, Samuel Klein wrote:
>
>> Erik, thank you kindly for the introduction.
>>
>> Bjoern, I should like to hear more about your idea.  You will inspire
>> me to publish my own use cases and suggested
>> simplest-possible-solution.  We have a small mailinglist where you
>> will find other interested users and developers of wikireaders:
>>  http://lists.laptop.org/listinfo/wikireader
>>
>> Regards from rainy Boston,
>> Sam.