[Zope3-dev] z3 in z2 land, zcml vs. yaml, and a new year

[tav]

rehi all,

i just spent the last week scouring through the zope 3 source, list and
wiki, and it's been one hell of a ride!

with the exception of zcml, i have been bloody impressed by everything i
have seen so far. a big thank you to everyone involved. it's been well
worth the wait.

unfortunately, the brilliance of z3 has placed me in quite a dilemma.
see, i wasn't expecting it to have reached the level of "stability" and
usability that it has. but now that i know, i am not too keen on going
back to zope 2 ;p

#/#

see, i am about to embark on the development of 2 related projects:

 - plex, a decentralised network with built-in indexes and event
   routers over which i am hoping to be build a component based
   application layer.

   see http://www.osian.net/wiki/technical_infrastructure for a
   brief technical overview.

   simply put, i am integrating zope with the likes of twisted,
   bittorrent <http://bitconjurer.org/BitTorrent/>, mnet
   <http://mnet.sf.net> and mod-pubsub <http://mod-pubsub.sf.net>,
   which combined with mozilla's xul power will hopefully enable
   a funky "zope on the desktop" =)

 - xnet, a groupware application that will start out utilising the
   web, but over time will use the plex as it's underlying network.

now, i had intended to do all this with zope 2. but, zope 3 has me
distracted and confused. i'd appreciate some guidance at this point.

#/#

if i am going to focus exclusively on z3, this effectively comes down to
assessing some particular features of z2, and how likely (and how soon)
they are to manifest in z3.

1. full webdav support.

   i used the webdav powers of z2 to hack together an object
   orientated filesystem (oofs). davfs <http://dav.sf.net>
   then enables me to mount this on the local hard drive and
   make use of it, e.g.

   $ cd music/artist.michael_franti/year.2001

   which dynamically creates a folder containing all the music
   by michael franti from 2001. another example:

   $ cd docs/p2p/p2p_overlays

   which dynamically creates a folder containing all the
   documents from my knowledge base relating to peer to peer
   overlays.

   as you can see, this can be very useful. unfortunately, z3's
   dav support seems to be in it's early stages. is this likely
   to improve soon? is it a high priority for anyone?

2. python scripts.

   i understand that persistent modules will be replacing
   the functionality of python scripts(?)

   do these exist yet? how does one go about creating them?

   will subpath be supported?

   i appreciate that the scripting community isn't one of z3's
   current focuses, but i would like to make it one.

   will these persistent modules be able to implement
   interfaces? i.e. could one verfiy that a given persistent
   module supports a specific interface?

   i see a lot of potential for introspectable components
   created ttw, and dynamically exchanged and utilised over
   the web/plex...

3. utilities.

   am i right in understanding that utilities are effectively
   "localised" services?

   how does one go about creating them? (can one create them?)

4. zodb throw-aways.

   i noticed a few messages suggesting that z3 zodbs need to
   be occassionally thrown away.

   and, as comfortable as i am with zope code. i cannot say the
   very same for the zodb. i simply expect it to work and leave
   it to itself.

   what causes the zodb deaths? is this likely to happen in the
   future? will i be able to export data from a dead zodb *after*
   it dies? i.e. do i have to backup every minute?

5. __used_for__.

   everyone seems to specify a __used_for__ in their views/adapters,
   but after much grepping of zope source code, i couldn't figure
   out what exactly the attribute is used for.

   is this merely a helpful convention for people reading the source,
   or is there some magick that i am not aware of?

besides uncertainties on the above front, i am very happy with zope 3
and would like to use it for my projects.

#/#

alternatively, i have considered implementing the xnet in zope 2, whilst
waiting for zope 3 to improve on the other fronts.

if so, i would like to use some features of z3 in z2 now, and would,
again, appreciate some guidance:

1. interfaces.

   i understand that z3 interfaces and z2 interfaces differ
   substantially.

   so, can i simply grab zope.interface and zope.schema from z3
   and use them in z2?

   i don't see why, but one can never be too sure in the magical
   world of z2. will things break if i do so?

2. new-style classes.

   why exactly are all classes in z3 new-style classes?

   can i simply use new-style extensionclass from zope HEAD,
   and then specify new-style classes in z2?

   does everything needed for this work now, or do changes
   have to be made still?

   can i use old-style classes and then move onto new-style ones?
   what are the implications of this?

   i apologise for my ignorance on this front, but would
   appreciate some enlightenment.

now, i understand that some of you (zope corp and martijn in
particular), have made use of z3 in z2 land.

is this true? if so, could you please provide some brief details? many
thanks!

#/#

finally, on the topic of zcml, i have to unfortunately express serious
discontent =(

i was obviously not there when the decisions were made, so arguably i
have no right to be discontent, but i shall make a plea nevertheless.

zcml terrifies me.

and, i am not alone in this regard.

zcml will be, as far as i can tell, the biggest barrier to zope3 adoption.

separation of component configuration is obviously quite attractive, but
i have to ask... is it necessary for it to be so "powerful" ?

it reminds me a lot of the rdf world, where certain attractive
abstractions were implemented, resulting in something so complex and
powerful that in 6 years of rdf, very little of value has been achieved.

secondly, if it's seen to be absolutely necessary, can we at least use
an alternative format? emacs with the nxml-mode makes zcml just about
palatable, but unless i had spent a *lot* of time developing in it, i
would still be terrified by it.

can i suggest yaml <http://yaml.org> as a potential alternative. e.g.
compare and contrast:

----
<adapter
   for=".interfaces.IWikiPage"
   provides="zope.app.interfaces.file.IWriteFile"
   factory=".wikipage.WikiPageWriteFile"
   permission="zopeproducts.zwiki.EditWikiPage"
   />
<event:subscribe
    subscriber=".wikipage.mailer"
    event_types="zope.app.interfaces.event.IObjectAddedEvent
                 zope.app.interfaces.event.IObjectModifiedEvent
                 zope.app.interfaces.event.IObjectRemovedEvent
                 zope.app.interfaces.event.IObjectMovedEvent" />
----

with something like:

----
adapter:

 for:		.interfaces.IWikiPage
 provides:	zope.app.interfaces.file.IWriteFile
 factory:	.wikipage.WikiPageWriteFile
 permission:	zopeproducts.zwiki.EditWikiPage

event:

 subscriber: .wikipage.mailer

 event_types:
  - zope.app.interfaces.event.IObjectAddedEvent
  - zope.app.interfaces.event.IObjectModifiedEvent
  - zope.app.interfaces.event.IObjectRemovedEvent
  - zope.app.interfaces.event.IObjectMovedEvent
----

the latter is, imho, far far easier to read and more pleasant to work with.

have a look at http://yaml4r.sourceforge.net/cookbook/#collections for
more examples of yaml data structures.

i hope my criticism on this front doesn't offend anyone. i am simply
keen to maximise adoption of zope 3 and make my own usage of it a
pleasurable one.

#/#

and, finally finally, can i propose starting afresh on a new zope 3 wiki
for the new year?

there's a wealth of information lost amidst the list and the current
wiki. but most of it is not accessible in an ordered manner, some of it
is out of date, etc.

starting afresh (on zope3.org?) will give us a good firm foundation to
point to and attract new developers. i am willing to dedicate my
energies towards this. how do i start?

#/#

despite my zcml criticism, it truly is an exciting time to be a zope
developer.

and, again, a big thank you to all involved. have a great new year!

-- 
best regards, tav
tav at espians.com