Package browser

[Hervé Eychenne]

On Wed, Apr 30, 2003 at 03:53:39PM +0200, Enrico Zini wrote:

> On Sun, Apr 27, 2003 at 02:53:04AM +0200, Hervé Eychenne wrote:

> I will continue these discussions in private, if you want, but I'd
> prefer to hold them in some public list, like
> deb-usability-list@lists.alioth.debian.org.

> Please consider Cc-ing the reply at least in that list, which is low
> traffic at the moment, so that others could take part.  Feel free to
> quote any of my parts of these messages in the Cc.

Ok, done.
I leave some of your paragraphs quoted without answer (when I agree or
have no particular comment) so that people reading this can have an
historic.

> > > I'd say that solving this belongs to the interface application, and we
> > > should very well ignore the issue for now.
> > I don't think this belongs to the application. Search facilities will
> > be used by any application using libtagcoll, and I don't see why they
> > should be duplicated (reinventing wheel over and over again) in any
> > application. I'm for code factorisation.

> Me too, but I'm also against bloating libraries.  So, at the moment
> libtagcoll provides algorithms to manipulate a database of
> item -> {set of tag} associations, and I'd like it to stay in that way.

> This does not mean we can't have a library that uses libtagcoll to
> provide search functions (and the other various useful functions you
> propose in this message) around tagcoll.

> I say this because search involves i18n.  Consistency checking against a
> vocabulary involves parsing and maintaining a vocabulary.  Validity
> checking against timestamps involves having a policy and a source for
> these timestamps.

> These are all useful things, these can also be common things that we
> want implemented in some common library for everybody to share, but
> these are not things we want linked against any possible little tool
> that works with tags and items.  Not only this, but someone might want
> to use the tagcoll algorithms and a different i18n system or validity
> check than the one we provide, and he has the right to choose.

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

> You can think about it as something like gnome having glib, gobject and
> gtk as separate things: it enables, for example, libraries like gdome2
> to get the portability defines and utility functions of glib while still
> remaining stand-alone libraries that can be used in any project, even if
> it doesn't have a graphical interface, or if it uses a different toolkit
> than gtk.

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).

> The idea is just that simple interfaces have to remain simple, and
> different kind of feature need different kind of interfaces.  This does
> not conflict, of course, with wanting to have a single source for well
> maintained, shared reusable code.

> > > > Why not... but what I think is that life of maintainers must be made
> > > > as simple a possible.
> > > > Patches, etc... seem very complicated to use. KISS (not especially at
> > > > the software level, but at the human one, Erich !! ;-)
> > > Complicate?  I'm talking about the tag patches produced by tagcoll: have
> > > you tried them? :)

> > I'm not saying that the thing is complicated by itself. But that
> > people who don't care about it should not have to play with it, just
> > answer simple questions from time to time.
> > That's what computer science is for: put intelligence in the software
> > as much as possible so as the human can concentrate on their real
> > values.

> Of course: that's why I wanted to develop this tag editing gui in the
> first place: so that one could generate a tag patch without even knowing
> what it is, and just plug the output file in the /etc/debtags/tagpatch.d
> directory of all the systems he wants.

> > > I can imagine that more than one maintainer will be more likely to lose
> > > a day complaining about the noise in their mailboxes than to loose those
> > > 30 seconds fixing things :)
> > If it's well done, there will be no noise. Just a simple mail from
> > time to time (depending how much important keywords were added since
> > the last one).

> This is one of those things where you have to let the community evolve a
> little bit around the idea and then see what structures will develop by
> themselves and what will be needed.

> > > Actually I was considering the idea of enabling package tags in Debian
> > > using just the central database as a start, then see what happens.
> > Oh, this is very humble... ;-)
> > But think of tagbk, and of things like catalog (Debian package
> > available). Libtagcoll could be used in so many things...

> Of course!  And it should...  Galeon or Epiphany could very well use it
> at some point.

Yes, absolutely!

> But since I'm not a software house, nor (yet) a
> developers community, I'll have to take one step at a time...

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. ;-)

> > > Simple: it just pops up in the wrong places, or among the wrong things :)
> > Or worse: keywords are missing, and packages will show too "high" in the
> > tree, and noone will make an effort to move it "down" in the tree, where
> > they better belong.

> Given the huge wave of suggestions and tagging efforts we've received
> just after the announcement, I'm now convinced that someone will make
> that effort :)

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/