Aubin Paul wrote:
> 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.
So internal we have a list of key-value pairs. In Pythons way of
naming things, this is a dict. Even you use use a database, I will
call it dict from now on to have a name for it.
> Completely generic. The calling application would just decided what
> it wanted to store and shouldn't ever care about the structure.
So key is a string, value is something else (complete python
objects). So we need to store a dict (dict, database key, different
files, whatever) 'file' -> info when info itself is dict key -> value.
> 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.
Sounds good. But how to identify the namespace. A variable _id_ inside
an item? Inside every object that uses the storage?
>> 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.
We should take carse that this doesn't slow down freevo. When
generating a directory listing, all items what there metainfo. This
needs to be fast or everything will slow down.
Dischi
--
"A Computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox
-------------------------------------------------------
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
