>  From: Walt Ludwick

...

>  The prospect of integrating these two applications into a ZwikiCard
>  solution seems fraught with certain challenges, most significant from my
>  preliminary analysis being essentially twofold:  (1) ASYNCRONICITY/
>  SHARED OWNERSHIP; and (2) LACK OF CONTEXT.  To further explain:
> 
>  (1) This is the  classic database-replication problem, essentially:  how
>  to have different people editing same data at same time (offline), then
>  merge without update conflicts.  These problems are well-known to anyone
>  in the "big-iron" world of relational database replication, and the
>  traditional solutions are pretty heavy, i.e.

...

>  Does this sound reasonable?

It looks like you thorougly covered the main issues, so I won't repeat them.
I agree the big issue is the database. Dan and I have talked about this a
bit within the context of his own Zope/ZODB applications. My basic answer is
let the database, ZODB, and the the wrapper application, Zwiki, continue to
do the heavy lifting since if the web interface is going to remain viable,
the rules and limitations they impose must still be in effect.

That means any client gets and puts data more or less as if you can invoked
an edit. Now, you don't have to "checkout" every piece of data, but when you
push something to the server it needs to follow the same rules as if the
user had pressed "Submit" so if another user edited the page in the
meantime... the desktop client acts accordingly.

You will probably need to have access to the package or modules being used
by the Zwiki on the local client. The local client should be able to
download and upload "raw" structured text data rather than having to process
HTML, but it should also be able to do "preview" renders on the client-side
without hitting the server, so you can avoid that edit/post/edit
fix/post/edit fix loop typical with web based editing. If the HtmlWindow
component isn't adequate you can simply call the same render method that
Zwiki uses against your structured text and display it with the local
browser using the webbrowser Python module.

Whether you want to cache a local copy of the whole ZODB database on the
client or just maintain a mirror of the pages in use is a design decision.
How much data is going to be kept locally will impact how much work can be
done offline and whether each record get and set has an associated HTTP GET
or POST even if the GET simply gets back a 304 not modified response from
the server.

I suspect that a lot of new ground is being broken here in the context of
Zope and how it expects to work. You could end up with a very feature rich
and complex content management system, but I think you should also be able
to make a very simplistic client-side editor that can interact with
non-public user data.

Patrick O'Brien has a project called Bulldozer (BDOZ) on SF

http://sourceforge.net/projects/bdoz

and he has been playing with a ZODB based addresses sample, addressesZODB.
The reason I bring these up is that he has added support in PyCrust (the
PythonCard shell) for inspecting Zope/ZODB data. I don't know if it is
possible to inspect a remote ZODB data store, but it can be used on a local
one and might help with the development effort of your app. Patrick can
probably elaborate or correct me here.

ka


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@[...].net
_______________________________________________
Pythoncard-users mailing list
Pythoncard-users@[...].net
https://lists.sourceforge.net/lists/listinfo/pythoncard-users