[Wikireader] Quick intro re: offline viewing/editing

[Bjoern Hassler]

hi Samuel,

thanks for the suggestions.

> 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.

I agree that some basic two way synch is the most interesting.

However, in a number of scenarios even one-way updating would already  
be helpful.

> 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.

These are all good suggestions - thanks!

More in a moment!
Bjoern

>
>
>
> 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.