Re: [Wasabi] Kicking of the Metadata spec - brainstorm

2007-02-21 Thread Vincent Untz
Le mardi 20 février 2007, à 23:08, Mikkel Kamstrup Erlandsen a écrit : 2007/2/20, Vincent Untz [EMAIL PROTECTED]: Le lundi 19 février 2007, à 23:35, Mikkel Kamstrup Erlandsen a écrit : Let's get the ball rolling on the metadata spec. This first period will

Re: [Wasabi] Kicking of the Metadata spec - brainstorm

2007-02-21 Thread Joe Shaw
Hi, [trimmed CC line] Mikkel Kamstrup Erlandsen wrote: How would you manage locks on the db? Assuming sqlite, you just let it handle them. You have to be intelligent in your use of transactions, but I don't see how a daemon inherently improves lock contention. Was synchronization issues

Re: [Wasabi] Kicking of the Metadata spec - brainstorm

2007-02-21 Thread Joe Shaw
Hi, jamie wrote: (3) is the safest and best way - you get a richer service that allows all apps to share metadata and stay up to date. (2) is great in theory but falls over in practice for loads of reasons (mainly need for fallbacks). XMP sidecar is better and really just needs GVFS and KIO

Re: shared wasabi implementation

2007-02-21 Thread Joe Shaw
Hey, Mikkel Kamstrup Erlandsen wrote: I think I mentioned getters and setters for metadata somewhere in this thread, but that's not entirely obvious from the context of the mail you reply to :-) The methods I suggested was only for ingesting in the index. Or are you saying that there should

Re: [Wasabi] Kicking of the Metadata spec - brainstorm

2007-02-21 Thread jamie
On Wed, 2007-02-21 at 08:54 -0500, Joe Shaw wrote: Hi, jamie wrote: (3) is the safest and best way - you get a richer service that allows all apps to share metadata and stay up to date. (2) is great in theory but falls over in practice for loads of reasons (mainly need for

Re: [Wasabi] Kicking of the Metadata spec - brainstorm

2007-02-21 Thread jamie
With approaches (1) and (2), notification is trivial. You get WRITE_CLOSE event and ATTR_CHANGED events on the files themselves. For (3), you can watch the database file for changes. (This means you have to timestamp rows, but once that's done you can trivially SELECT for

Re: [Wasabi] Kicking of the Metadata spec - brainstorm

2007-02-21 Thread Joe Shaw
Hi, On Wed, 2007-02-21 at 14:26 +, jamie wrote: Sorry, I must not have been clear in my previous email. The entire point is to have fallbacks, because it gives you the richest experience. You try (1) [inline metdata] and if it fails or doesn't make sense, you try (2) [extended

Re: [Wasabi] Kicking of the Metadata spec - brainstorm

2007-02-21 Thread Mikkel Kamstrup Erlandsen
2007/2/21, Fabrice Colin [EMAIL PROTECTED]: On 2/21/07, Jos van den Oever [EMAIL PROTECTED] wrote: 2007/2/20, Joe Shaw [EMAIL PROTECTED]: Heh. Fair enough. Should we keep it simply to the search-side of things, then? The intention is to define a way to define metadata fields. This is