Kevin Altis wrote:
...
> Walt, it would probably be helpful for you to list specific problems you see
> with a pure zwiki or pure desktop app approach and specific features or
> requirements for an "ideal solution". Then, even if we don't have those
> features yet, they will at least be identified so we can decide if and when
> to incorporate them into PythonCard.
...

Hey, Kevin:  Thanks for the welcome - and invitation.  OK, i'll try to 
address this as best i can from the 50k-foot perspective of a "naive" 
user of Zwiki, knowing nothing about PythonCard but what i've read.

NB:  Since my Friday message, a new development ("BlogFace," by Karl 
Anderson) has been brought to my attention, which Simon Michael (Zwiki 
developer) is evidently working to integrate  (see 
http://www.zwiki.org/ZwikiAndBlogFace ).  This development seems to 
avoid one of the compromises that i am most disinclined to make (i.e. 
going out on a code-fork limb, e.g. 
http://webseitz.fluxent.com/wiki/FrontPage), and seems likely to yield 
some sort of "ZwikiBlog" (to posit a new WikiWord) solution that should 
be worthy in its own right.  I am keen to see what sort of shape this 
ZwikiBlog will take, before attempting any definitive analysis in this 
problem space.

Still, i can address the fundamental problems that i think it safe to 
presume that no server-side solution is going to solve.  I love Zwiki, 
and want more than it is giving me at present.  I want a solution for 
blogging to Zwiki using a handy desktop tool, ideally built in 
PythonCard. (let's call it "ZwikiCard," for want of a working title). 
 Why?  The problems i have with Zwiki alone are essentially threefold: 
 it's (1) too SLOW, (2) too OPEN, and (3) too INFLEXIBLE.  To be more 
specific:

(1) Browsing and occasional posting via web forms is fine, but for more 
granular/ intensive editorial work (i.e. many Create and/or Edit 
operations) having to await an http transaction at every turn is just 
too *slow* - especially for people (like me and my neighbors here in PT) 
with slow (and expensive) dialup connections (NB:  here in Europe, we 
pay local telco for each "pulse" of connect time, if not the ISP as 
well).  For weblogging, we want a tool as fast as thought itself, but 
certainly no slower than our ability to type out our idea, decide where 
to publish it, then move on to the one that follows on its heels.  If 
the tool is significantly slower, then the iterative flow of 
thought-processing (i.e. reading & writing, asking & answering 
questions) is blocked, and we'll either work independently, or via some 
faster (off-web) communication channel.  A related issue (under the more 
general rubric of "access") is *reliability*: temporary disruption of 
weblog server operations can be suffered (unless your blog is a 
mission-critical infrastructure element for fellow worker[s] in a 
knowledge web), but if this tool also serves as your PIM in effect, this 
becomes a productivity hit that you'd rather avoid by using a desktop tool.
       
(2) Of course *openness* is the cardinal virtue of the web, but there 
are limits to what we will expose of ourselves on the web.  So we have a 
body of work on the web, and another body of web on the desktop - with a 
corresponding persona that we wear in each of these contexts (a sort of 
"split personality" phenomenon) - and weak mechanisms for moving things 
from the latter context to the former.

(3) *Flexibility* is an issue with any web application (even those that 
go off the deep-end of "personalization options" madness), inasumch as 
you can't personalize the interface*, without getting into the code-fork 
problem i roped-off above (*unless it could be "skinned" somehow - maybe 
using Mozilla XUL?).

NB:  For all this, Zwiki is still the tool for collaborative thought 
processing that i've yet encountered - and that's the essence of what we 
want to do as much as possible.  Still, dekstop tools are the best for 
peformance, privacy and flexibility;  that's why i want to 
create/integrate one.

As far as desktop applications are concerned, there is really just one 
problem they all suffer to some extent - but it's a big one: ISOLATION. 
 For all of the reasons above (and others, no doubt), we all make notes 
as we work on our desktops;  the trick here is to enable integration of 
our desktop work with the (Zwiki) web in such a way that important 
values on both sides are respected (i.e. community norms on the web, 
privacy on our desktops), and the whole becomes greater than the sum of 
its parts.  We want to gestate & process ideas in a secure, fast and 
flexible environment, with an easy way of publishing them to web when ready.

So, what our emergent ZwikiBlog probably wants out of PythonCard is a 
"power-user" front-end incorporating several important functions:

- WRITE new cards, with date and authorship attributes automatically 
generated;
   -- LINK to existing cards (perhaps retrieved thu active browsing, or 
better thru magic of WikiName invocation, if possible);
- PUBLISH, selectively (keep in mind, the idea is to get over the "split 
personality" sydrome cited above, by enabling one to work for a spell 
without circumspection, then do some decisionmaking about what to 
publish and where).

Also, if this to be integrated meaningfully with the wiki (not just 
living beside it without interaction), you need some additional 
features, i.e.:

 - DOWNLOAD contributions (comments) others have made to your page, and 
(selected) pages of other users that have changed since last download 
(i.e. IMPORT context);
- COMMENT on pages of others (incorporating links to previously 
published material in both these comments and your own pages).

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.
- checkout/ checkin of pages (a la CVS) or contained objects (i.e. 
"row-level locking");
- referential integrity constraints (to avoid deletion of material w/ 
dependencies);
-  transaction boundary controls (i.e. commit/ rollback);
-  industrial-strength TP monitors (e.g. Tuxedo);
...etc.  At this point, i'm losing my appetite, so i think rather than 
go down that road, we want to scope our application appropriately (i.e. 
small), with clear (i.e. personal) ownership of page/elements in new 
content areas (i.e. not pre-existing) unlikely to be disputed.  
This  suggests to me the shape of a conceptually viable ZwikiCard 
solution:  in this sub-section of the wiki that is the zwiki/BlogSpace, 
there is a page corresponding to each BlogKeeper - perhaps with child 
[archive] pages -  and that user exercises sole editorial control that 
page-body, tho anyone can append comments to another's page (subject of 
course to later deletion by the editor).  This is of course a gross 
oversimplification;  we probably need (once the backend ZwikiBlog 
solution settles into some reasonably stable form) to identify each 
object class implicated in use cases with any actor, and assign CRUD 
(Create, Read, Update, Delete) permissions  for each actor on those 
objects accordingly.

(2) To whatever extent we sidestep the aforegoing problem by (a) 
introducing the notion of page/element ownership into the wiki, and (b) 
keeping the scope of this new reality small enough that it does not 
spoil the prevailing wiki-magic, then we leave ourselves with the 
attendant *lack-of-context* problem to solve.  While the domain of 
desktop idea processing solutions could be fairly characterized as "the 
sound of one hand clapping," the the last thing you want to do is 
project such publishings into wikispace without reference to the 
material that forms its context.  

This suggests to me that our application should be smart enough to 
recognize alert us to dependencies, within the material that we have 
selected for download, on other material that we might also like to 
download.  NB:  Since this is not simple "upstreaming" (i.e. one-way 
flow, a la Radio Userland), but rather a synch operation (2-way flow) 
with a periodic polling to check for anything new on either end, there 
needs to be a mechanism for resolving conflicts, i.e. any new comments 
that may been written to Zwiki while you were editing need to be 
retained (as i can't imagine anyone wanting to overwrite them blind) and 
flagged in some way (as the comment and the edit may not make sense 
together otherwise).

Of course, as any wikian would be quick to point out, this new form of 
"WikiSpace" i am positing is no longer wiki exactly, but a rather hybrid 
that i like to think can live in healthy symbiosis with both wiki and 
desktop.

Does this sound reasonable?


|/|/alt


_______________________________________________________________

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