RE: [Pythoncard-users] Re: any feature requests?

[Kevin A. <al...@se...>]

> From: Peter Cleaveland
>
> What's the best candidate to provide the implicit card-level persistence
> HyperCard had?  Not to mention a place to store the code and resources,
> when we get to the point of having a PythonCard IDE.

I don't think we have a best candidate. What we discussed when the list
started was a generic card or record class that would support a variety of
backend data stores (repositories). The textIndexer sample uses ZODB. The
addresses sample uses a list of dictionaries. Neither of these samples has
been generalized for any app to use, but I plan to do a sample at some point
that builds on the resourceEditor and lets you create simple flat-file
databases as we explore our storage options. For metadata, dictionaries and
dbms work fairly well. Given the large amount of RAM available on most
machines today we might be able to use a model that keeps all of the
metadata and data for an application in memory, but writes changes out to
disk as they occur.

At a minimum, we would support getRecord/setRecord, getField/setField type
calls and some rudimentary searching and sorting framework against the
wrapper class. We'll need to provide dot notation access, regardless of the
underlying storage method. This means that applications that want to
optimize their data handling will still need to use SQL or ZODB directly in
order to get the best performance.

I encourage you and others to write your own samples exploring possible
storage methods, just keep in mind how any solution you try can be
generalized for a larger class of applications. Once we get through some
more of the direct GUI issues, I'll get back to this subject area myself.

> Shelve leaps to mind, but I'm not sure the DB files Shelve creates are
> portable across platforms.  Shelve also seems to create more than just a
> single file, which is non-optimal.

I don't know that multi-file is really a problem, the metadata and real data
can simply go into a sub-directory. In particular, artwork (MPEGs, WAVs,
MP3s, JPEGs, cursors, icons, fonts, etc.) are difficult or inefficient to
store as text, nor does it make sense to pickle that kind of data or stick
it into a database. For static data, we discussed using the zip support that
is part of the standard libraries to get the equivelant of a Java .jar/.war
(web archive) file. What we can do is write a wrapper class to handle
reading these resources so that they can be transparently retrieved from
either a zip or directory or URL without the user code worrying about which.

A critical difference between a PythonCard app and a normal GUI app should
be that users can expect to be able to make modifications to the original
application and that means making sure access to all the component parts is
relatively simple.

ka