On 9/28/07, Joe Shaw <[EMAIL PROTECTED]> wrote: > Hi, > > On 9/28/07, Kevin Kubasik <[EMAIL PROTECTED]> wrote: > > Its important to realize that my focus is not on the implementation of > > a backend to store this information, but to provide a generic way for > > us to include 'tag' information from a variety of sources. > > Often you can't separate implementation details from the list of use > cases, though. Yeah, to a large extent were stuck =/ > > Originally I wanted to do tags solely using extended attributes on > files. There are some definite advantages to this, like the ability > to maintain tags when files are copied around. But this decentralized > model does not lend itself to doing, for instance, tag clouds. > There's no way to get a list of all possible tags in a decentralized > model without walking the entire file system tree -- obviously a > non-starter. Yeah, that was actually my first thought, since it just seemed like the most fitting solution, as the tags would actually be with the files. > > So before worrying about parent-child tag relationships too much, > start off simple and refine the design as you go along. What do you > anticipate the uses for tagging on the user side? What uses would a > programmer want for tags, and how might this API look? How do > different (broad) implementation strategies fit into this? No doubt > you'll have to make compromises somewhere. Hmmm... well, the dream solution is always nautilus getting a slick tagging ui, problem is, I'm not really a slick-ui-writer guy. However, with the beagle plugin already in thunderbird, theres potential for integration there. Downside is there have been attempts at a universal tagging library, what i would really love (in an ideal world) is if we crafted events through the indexservice, meaning that while we could offer a way to work against the tags from the BeagleClient API, you wouldn't have to implement it. However, for tag querying/listing, we would probably require a native API.
The specifics of how much of this were going to make beagle responsible for (is beagle almost like a 'tagging adapter'? do we want to provide complete bi-directional support? or do we encourage people to work through the provider that we are using as a backend?) I have a strong feeling that in the end were going to end up with a sqlite database that we are maintaing and working against, which isn't the end of the world, I would just prefer that instead of Beagle trying to provide a robust tagging api, we just integrate it into our search intelligently, and treat it as a property. That being said, until the querying component works successfully, I really don't want to get to excited about the other direction. > > > Also if anyone knows of a smart way to take a bunch of > > internally-mapped Uri's and merge them with the existing result sets, > > I'm still getting some frustration on that point, while I've figured > > out the functional steps that the bitarray's serve (as in where to put > > one when I want to search an index etc) once I've run the query to > > fill/populate it, I'm not really sure of what I can do with a > > LuceneBitArray or BetterBitArray. Anyways, I'm sure I'll eventually > > get it, but help would save some painful slow debugging time. > > I'm not totally sure what you're trying to do here, but I would > suggest (a) keeping the primary storage of tags totally separate from > the index and (b) dealing only with real ("external") URIs and pushing > changes out to the tag DB as needed. That would probably require some > additional events or something to be added to the FSQ. Well, the problem here is, I really don't want us to be tied to one index, or one backend. I would think (and I could be wrong here) that once we have merged the results from a backend, we could add any Uri's that were tagged with one of the query words. The key point here is to have a universal tagging store that transcends our backend system. I think I might be misunderstanding, but its not the storage of the tags, its that a tag query has 2 defining functions (in my view, im open to a different interpretation) 1) If an item has a tag, that tag should appear as a property (to the client). I think this means we need to catch Hits before they are returned and add another property (when appropriate) 2) If a query matches a tag, then all of the tags Uri's should be returned, this is where I'm getting really caught, because I can't quite figure out how to take a pretty outside Uri and get a complete Hit back. I'm not really sure where that wires into the FSQ and more than the other queryables. > > Or, if you're feeling particularly adventurous, rewrite the FSQ. > That's the biggest consumer of memory at this point and has problems > like being unable to search by parent directories. I've described the > issues with it in more detail in a previous email, I believe. :) I seem to remember something about that. Its probably overkill right now, with the slew of new features, but I am curious about it from a design standpoint. > > Joe > -- Cheers, Kevin Kubasik http://kubasik.net/blog _______________________________________________ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers