On Sun, 2005-08-21 at 20:13 +0200, Martijn Voncken wrote: > The downside is that only advanced users can add > ATTR_SEARCHABLE,ATTR_INDEXED or ATTR_KEYWORDS columns. > I do like the idea of the ATTR_KEYWORDS column.
This is a problem that can be solved in the UI. If the UI wants to let the user add his own attributes, then he can do so, but he'll need to get some more information from the user about the nature of that attribute. "IS this something you're going to want to search on? If so, will you want to do word searches, or will you only want to match the entire value?" These new attributes can be registered with the vfs at runtime with the appropriate ATTR_* flag. > Some tagging formats allow searching/organizing on > custom/non-predefined attributes it would be really great if they are > automagically searchable , but few media players support something > like that. Ok. I do understand your way will make this drastically easier. But IMHO, it's simply not worth it. What percentage of the userbase will use this feature? What is the performance hit in implementing something like this? Is it justifiable? If we decide it is, we should be able to add a general purpose metadata table to accommodate this using my approach but without changing the design. But I suggest we do this later. This is a feature we can bolt on after-the-fact and while it might perform worse for these kinds of queries, the common cases should be much faster. Jason.
signature.asc
Description: This is a digitally signed message part
