RE: [Pythoncard-users] evaluating shelve module

At 2:08 PM -0600 2/7/02, Patrick K. O'Brien wrote:
>Ooh, ooh, yes! I agree completely. At least at this point in the game. Let's
>pick one object persistence method and take it to the extreme. I think we
>should decide between MetaKit and ZODB. They seem to be the strongest
>options at this point. Anyone who wants to do SQL can still do so. But I'd
>really like to pursue one way of persisting Python objects from Pythoncard.

For my purposes, ZODB is the answer. Several of my apps are going to 
be adjunct to existing Zope sites.  MetaKit does not do anything for 
me. So my vote is we concentrate 100% on ZODB and go for it.

>---
>Patrick K. O'Brien
>Orbtech
>
>>  Dan Shafer wrote:
>>
>>  I'm inclined to buy into the idea of a broader solution integrating
>>  the persistent store at the core of the document model into the
>>  framework architecture more tightly than just using an existing
>>  storage mechanism sort of "as is." Smalltalk, in particular, has
>>  developed some very strong and nicely generic design for
>>  change-notification mechanisms (though its native object persistence
>>  has always been a major gap).
>>
>>  OTOH, I think we need a sort of default mode for persistence that is
>>  simplified from a generic architecture and that can be transparent to
>>  end users (inventive users, scripting users, power users, whatever we
>>  want to call them), including those who want to create applications
>>  that rely on auto-storage of objects and documents without worrying
>>  about how that happens or understanding it.
>>
>>  So I'd suggest we architect the persistence mechanism into the
>>  framework API in such a way that the designer who is cognizant of
>>  storage alternatives or who is designing in an environment where the
>>  store is pre-determined can either use an existing component that
>>  handles that effort or follow clear guidelilnes for writing a
>>  component for a specific data storage need.
>>
>>  I'm also strongly predisposed to suggest that we emphasize _object_
>>  store rather than relational models, which are always kludges when it
>>  comes to serializing and storing objects of any depth or complexity
>>  at all. Not to say we shouldn't allow SQL data storage of information
>>  stored in PythonCard applications, but only that our design and our
>>  default ought to be OO to the core, like the beautiful language we
>>  are using to craft it.
>>  --
>>  Dan Shafer, Author-Consultant
>>  http://www.danshafer.com
>>  http://www.shafermedia.com
>>
>>  _______________________________________________
>>  Pythoncard-users mailing list
>>  Pyt...@li...
>  > https://lists.sourceforge.net/lists/listinfo/pythoncard-users


-- 
Dan Shafer, Personal Creativity Trainer and Consultant
Trained Hartman Value Profile Analyst
http://www.danshafer.com/valueprofile.html