Package browser

[Erich Schubert]

> The fact that some functions are present in a library does not force
> anyone to use them.

The fact that people might want to not use certain functions is usually
a sign that you could / should build a derived library.

> But glib and gtk are much bigger than libtagcoll. So if you keep
> search facilities out of libtagcoll, we will have two small libraries,
> doing quite connex things (if not overlaping in some cases).

No, you have one library which maintains the vocabulary, searches in the
vocabulary for matching tags, and then _calls_ the tagcoll library to
search for matching packages. Tagcoll doesn't know anything about the
meaning of the tags, it only knows about the dependencies.

Tagcoll libraries mustn't be tied to a specific file format either. We
already have to differnet tag storages (sql, files) and specifics such
as the patch files.

glib is a good example. It used to be a part of gtk, but was split out
because it's really useful without gtk as well. Still gtk needs glib.
gtk leaves list and hash handling to glib.

> Of course. Handling of bookmarks could exactly be one of the
> applications, for example. It would be _so_ useful... but I know this
> is what your tagbk (http://people.debian.org/~enrico/tagbk.html) is
> all about. What you have to do now is port it to use libtagcoll. ;-)

But these bookmarks need a different way of i18n, timestamps and such.
A user probably isn't interested in knowing which bookmarks havn't been
re-tagged since the introdcution of a new tag and such. And he doesn't
care about i18n, only predefined bookmarks by distrbutions might make
use of such. Also no user will bother to write descriptions or long
titles for his tags, so there is no use for a string search facility
inside tagcoll.

Greetings,
Erich Schubert
-- 
    erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
   A polar bear is a rectangular bear after a coordinate transform.  //\
  Wer nicht zuweilen zuviel empfindet, der empfindet immer zuwenig.  V_/_