Re: Re: What does Five and Z3 mean for Archetypes?

Hi there,

Was away for a few days so dropped out of this thread; my apologies. I'm 
picking it up though.

Rob Miller wrote:
[snip]
> i'm currently maintaining the ATSchemaEditorNG product, and have been 
> thinking about ways to use Z3 technologies to improve dynamic schema 
> management.  i've been imagining ISchemaProvider and ISchemaConsumer 
> interfaces, with the one obviously feeding schema definitions (which 
> could be python code, TTW-edited, XML defined, whatever) to the other. 
> i've imagined these to be AT schemas, with possibly a bridge from Z3 
> schema definitions working as well.  if we can concretely identify a 
> schema implementation that those converge on, however, even better.

Agreed. Of course knowing Zope 3 schema better I'd prefer if we 
converged on that, but I can imagine it still misses features that you 
need or that there are some philosophical differences.

> it may be worth creating a relatively exhaustive list of the features 
> currently present in AT schema-land that are not in Z3, the reverse, and 
> any notable philosophy differences between the two, so we have a better 
> understanding of exactly what the gap is.

Yes, this would be very useful! I can help with the Zope 3 part of this. 
Would you like to kick off creating this list, as you are familiar with 
both systems?

>>>> It may be that this proposed route is presumptuous towards AT 
>>>> developers however. I am curious to see more discussion of this. 
>>>> Again, one of my important motivation is to make sure the various 
>>>> Zope codebases and platforms can more easily exchange code, so that 
>>>> I can benefit better from your work (and you better from mine). This 
>>>> makes it essential I'm on the same page as the AT developers with this.
> 
> i don't consider your route presumptuous; on the contrary, i'm thrilled 
> to see you piping here on the AT-devel list, and that you have an 
> interest in helping with this convergence process.  

That's great to hear! Sorry I was away from the discussion for a bit, 
but I'm listening. :)

> my big concern, one  that i'd wager is shared by many, is merely that of being able to 
> preserve the significant investment that i've already made in working 
> AT-based code.  i'm very interested in a convergence path solution, 
> provided that my use cases continue to be met and there is a clear 
> migration path forward for my existing AT based systems.  gradual 
> evolution is the key to this, i think.

Agreed, as would be expected from the person who started the "evolution, 
not revolution" meme. :) I understand perfectly people have made a 
massive investment and that we can't just break things.

[snip discussion on using events]

[refernce engine]
>> It might be nice to write a reference engine codebase that can be used 
>> in Zope 3 as well, if at all possible. I'm not entirely clear on the 
>> scope of such an engine though -- perhaps it also needs specialized 
>> widgets, and so on.
> 
> the reference engine is actually one of the easier pieces to separate 
> out of AT.  currently, objects are referenceable by virtue of inheriting 
> from Referenceable and CatalogMultiplex (since the reference engine is 
> implemented via the use of a number of catalogs); we merely change these 
> to IReferenceable and ICatalogMultiplex interfaces and it immediately 
> becomes easier for non-AT objects to play.

Would it be possible to let these objects play by being adaptable to 
these (probably with the help of annotations) as opposed to having to 
implement the interface itself?

> it would also be possible, and probably desirable, to have the reference 
> engine implementation be componentized out to allow for new ones to be 
> plugged in.  i have to say, however, that the existing reference engine 
> is actually not "very slow", as you say.

Clarity for posterity: Note that I didn't say the reference engine is 
slow -- that was Martin Aspeli. I wouldn't know myself. :)

> what IS slow is the 
> convenience API that is commonly used (i.e. the getRefs call).  if, 
> however, you go directly to the catalogs within which the reference 
> information is stored, it is quite possible to use the current 
> implementation in a very efficient manner which will scale quite well.

[snip widgets]
>> zope.app.form has the widgets, zope.formlib puts the schema 
>> information and the widgets together.
>>
>> zope.app.form widgets are fairly simple, but also need work; there's a 
>> monstrous 'SimpleInputWidget' that isn't simple at all, and fits the 
>> worst of Zope 2 traditions, including the 'Simple' naming. :) Luckily 
>> it can be avoided.
>>
>> Perhaps archetypes can use Zope 3's widget system in the future, 
>> assuming here that Zope 3's system is less beyond redemption than 
>> Archetypes' is. :)
> 
> i suspect that the best thing to do here is to take a good look at what 
> we like about both the AT and the Z3 widget systems, merging those 
> together into something that is informed by both.

Right. I would of course prefer if the Z3 widget system were improved as 
a result of that, but that leaves the AT people in the dry. I wonder 
whether it would be possible to allow Z3 widgets and AT widgets to 
coexist for a while to serve evolution...

[storage mechanism]
>> Zope 3 right now doesn't have a storage mechanism equivalent, so it 
>> needs some work in this department. I do imagine the component 
>> architecture can indeed help making this cleaner.
> 
> yes.  AT's current storage mechanism is horrendous.  each field has it's 
> own storage abstraction, which means that saving 5 field values to a SQL 
> back-end will result in 5 separate SQL queries being executed, even if 
> the values are all in the same table.  ugh.
> 
> i think we can learn a great deal from (i'm being serious) ZPatterns 
> here... ZPatterns has handled data storage abstraction better than 
> anything in zope before or since.

Cool to see the ghost of ZPatterns returning. Phillip Eby is of course a 
seriously smart programmer and this route sounds plausible to me for 
that reason, even though I never actually worked with ZPatterns. :)

> we should push storage activities to 
> the end-of-txn, just like indexing, but we should also have some storage 
> delegation objects which understand the storage needs of each schema and 
> are able to perform the storage/retrieval operations efficiently.  this 
> is a big conversation, though, which i won't try to initiate here.

All right, let's delegate this for later. I hope we can move these 
abstractions into a Zope 3 library which can then also be exposed 
through AT.

[snip]
>> Thanks for the information about what's going on with Archetypes! I 
>> hope my input has been at least somewhat useful, even though you're 
>> not getting much in the way of straight answers yet. :)
> 
> your input is extremely valuable, thank you.  as i mentioned before, i'm 
> ecstatic that you have an interest in working w/ AT developers to bring 
> about a convergence.  there are a lot of good ideas out there, and a lot 
> of good work has been done; i'm looking very forward to all of us being 
> able to use more of them, more efficiently.

Thanks! I am very interested in bringing AT facilities into Zope 3 and 
Zope 2/Five and am very happy to hear that this route seems to be 
acceptable in principle to AT developers. The trick is to align 
interests between Z3/Five and AT so that AT gets concrete progress as 
well. I'll try to juggle time to keep this conversation going. Hopefully 
eventually we can take some steps to move forward -- I'll try to do some 
pulling while the AT developers do some pushing and that way we'll 
slowly bring the thing forward into the future together. :)

Regards,

Martijn


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click