On Wed, Dec 10, 2003 at 05:52:51PM +0100, Dirk Meyer wrote:
> Agreed. But maybe we could store the mmpython data ourself and bypass
> the mmpython cache?
What would be ideal is if we could override the mmpython cache
(inherit, whatever :) and then replace the write commands with our
own which could store extended information.
> So MetaStore is a dict containing variables for a 'file' (not an
> item)? The big question is: when is this informationen added to the
> item? Should each item call the util.MetaStore function? Or could it
> be simpler? We will only need the data through the getattr function,
> maybe this function could add the meta info if not loaded?
Not even a dict; just a general a=b type storage. Completely generic.
The calling application would just decided what it wanted to store and
shouldn't ever care about the structure.
i.e.
myfile.store('A','B')
would store A=B and you access it with myfile.get('A')
The storage would track where it was called from so the storage would
have:
audio.coversearch.A = 'B'
so there could be a namespace, but it would be possible to share
between plugins or keep them sandboxed.
> How to store the data? One file for each file will slow things now,
> one file at all may be too huge. One file for a directory like
> mmpython uses may be a good idea.
Fine with me... it would be generic eventually so we could use SQLite
etc.
> Maybe use shelve.py?
I'm not familiar with it, but I'll take a look.
> Maybe remove the links to the current player in the items and store
> the whole item?
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
