Le 23 août 07 à 07:33, Yen-Ju Chen a écrit : > On 8/20/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: >> On 8/20/07, Quentin Mathé <[EMAIL PROTECTED]> wrote: >>> Hi everybody, >>> >>> Here is a lengthy mail to describe a proposal about a Tag Object >>> System which would be implemented by an improved version of >>> OrganizeKit playing the role of CoreObject name service. It is >>> inspired by OrganizeKit itself and a discussion on SILC with David. >> >> One thing I cannot decide is how to store the data on file system. >> The current implementation is in a single property list. >> If you want to use it for everything, database may be better, >> but will be slightly slow. >> On the other hand, database ususally provides machenism for >> transaction while property list doesn't. >> So that is the only thing I am concerned. > > This has been mentioned before, I guess. > http://www.dekorte.com/projects/opensource/tagdb/
I remember we talk about it on SILC with alex (from XMMS2) :-) alex took a look at it because XMMS2 is working on a similar db called S4. More: <http://wiki.xmms2.xmms.se/index.php/ New_medialib_backend> There are explanations about their collection concepts which are very close to OrganizeKit ideas: - <http://wiki.xmms2.xmms.se/index.php/Collections> - <http://wiki.xmms2.xmms.se/index.php/Collections_Concept> I didn't precisely remember what I thought of it, but I would say that OrganizeKit looks simpler yet as flexible because it stores everything in term of nested key/value pair. This is unlike S4 which enforces two triplet-types: Entry-HasProperty-Property and Entry- Contains-Entry. Entry-HasProperty-Property is equivalent to key/value pair if you consider the following plist: { Entry = { Property = "value"; }; } So Entry-Contains-Entry is just a subcase probably used in order to achieve better performance. > We can seriously consider it as a backend of OrganizeKit > instead of property list if we plan to use it for system-wide tag. > I never really look at it, but two advantages I see: > (1) in-memory search, which is the reason OrganizeKit use > property list. > (2) transaction using qdbm, which is exact what OrganizeKit lacks > now. I'm all in favor of it, API looks clean. By the way , we should have a chat over SILC to discuss how to bring together OrganizeKit, TagDB and EtoileSerialize in CoreObject context. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
