durusmail: durus-users: Schevo and moellus [was: Re: [Durus-users] snag with btree.get(key)]
snag with btree.get(key)
2005-07-07
2005-07-07
2005-07-07
2005-07-08
2005-07-08
2005-07-08
2005-07-08
2005-07-08
2005-07-11
2005-07-08
2005-07-08
2005-07-08
2005-07-08
Schevo and moellus [was: Re: [Durus-users] snag with btree.get(key)]
2005-07-11
Re: Schevo and moellus [was: Re: [Durus-users] snag with btree.get(key)]
2005-07-13
2005-07-14
2005-07-14
2005-07-14
2005-07-13
2005-07-07
Schevo and moellus [was: Re: [Durus-users] snag with btree.get(key)]
Mario Ruggier
2005-07-11
I have looked over schevo's duru.py. Apologies in advance if I get things
wrong here... my first impression is that yes there are a lot of
similarities, but yet a lot of differences, and to evaluate properly one
would need a certain effort -- that people would physically be able to
invest. Me, and probably yourself, included, as we both have other things
claiming priority. But, what occured to me is that we could for starters
probably collaborate in a very simple way, with minimal effort, and likely
with mutual benefit...  i am thinking of two really simple ways:

- "converge" on an example by which to demo (tutorial) each framework.
This way, both of us, but also other onlookers, can see how the same thing
is done (or is not done) by the two frameworks (similar to pyweboff if you
like), and our understanding of the other frameworks improves. Plus,
working on examples and demo's is really time consuming, as for sure you
know. Thus, feel free to steal and morph my example if you like it, or i
can do that with yours... or find a new one, that we both can use.

- start and evolve a list of "characteristics", of how we see them, for
each framework. This could be simply a wiki page on your trac site (mine
is private). And, i am not thinking of a marketing-type feature list, but
more architectural and implementation choices, of how we see them for each
framework. Features in one may ofcourse be missing in the other. This
exercise can end up with a list of characteristics, the may also prove
useful for other things, as well as improve mutual understanding. Looking
over duru.py, i can throw out some examples (i may have understood things
very badly here):

- "Container visibility": Schevo seems to "hide" away the container
(extent) from the client. Moellus makes it explicit, with the intention
that you may want to add custom behavior for specific containers, and how
you would go about doing it is obvious and natural.
- "Predominiant feeling: relational or OO": Schevo seems to be trying to
respect, in spirit, more the terminolgy and data structures of the
relational world
- "Persistent Objects vs. Entities": This may be similar to previous (and
I may be totally off mark here) -- am I correct in my suspicion that
Schevo stores an entity "in chunks across differnent structures" as
opposed to a simgle persistent instance? When you load an entity, is it
simply unpickling it, or does it involve also "initialising" an object?

And so on... I understand that this could be a long discussion and we may
want to take this offline.

Again, forgive me if I have misundertood the first scanning of duru.py.


> Watch out!  A predecessor to Schevo was bdoz (bulldozer), an attempt to
> merely make ZODB easier to use.  ;-)

Wow, but it had a cute enough name !!
Why did it fail?


> I don't know too many people trying to do what we are doing, and hate to
> see a dilution of effort.  On the other hand, I understand the desire to
> do your own thing.  Mostly I just wanted to make sure you were aware of
> Schevo in case you hadn't heard of it.
>
> Good luck with moellus.  Let me know if you ever have the time to take a
> look at Schevo.  It would be interesting to hear your perspective.

I would be very happy to share, but it is always a question of what we
must do first, at any given moment... but evolving a wiki page as
mentioned above, whenever something occurs to either of us, may be
workable.

mario
reply