Re: Faceted tags

Enrico Zini dijo [Thu, Apr 08, 2004 at 06:22:13PM +0100]:
> (...)
> Instead, if you want to see what kind of compilers are in Debian, you
> choose devel::compiler and see what languages you can compile.

But then, you'd have to somehow distinguish things like Python, Perl
and Java which effectively are compilers, but not in the sense every
user expects it - devel::compiler::notreally?

> I tend to differentiate "server" and "daemon": "daemon" is a program
> without interface, while "server" is something providing some service to
> clients.  For example, we can have a "daemon" which is not a server, and
> maybe just samples data and writes them to disk.

Ummm... A daemon can have an interface - For example, editing the
configuration and sending a HUP can still be seen as an
interface. Some daemons can offer an interface to change some
parameters at runtime. This can quickly get too baroque - I agree with
your point, but am just ranting to show we can get a categorization
set (both with and without facets) too large to aid a user - it can
even stand in the way for a user.

> The full x11:: tag list I have so far is:
> 
>   Tag: x11::display-manager
>   Tag: x11::window-manager
>   Tag: x11::xserver
>   Tag: x11::screensaver
>   Tag: x11::terminal
>   Tag: x11::font
>   Tag: x11::libraries
>   Tag: x11::application
> 
> I think of it more like packages as seen by Mr. X11 than something
> specific to some technology, that's why I put it outside of tech.
> Also, I think it's self-contained and coherent enough to stand alone. 

Maybe a pseudo-nested facet can be a good compromise between your
ideas and Erich's. Think, for example, on how Perl modules work - We
usually think of modules in a hierarchical way. For example, I am
maintaining PDF::API2. It contains modules such as
PDF::API2::TrueTypeFont and PDF::API2::Chart::Pie - They are useful
for humans, we recognize them as part of the larger PDF::API2
namespace. In practice, the namespaces are all different and are not
linked except by other data (such as the @ISA array for
inheritance). When resolving a symbol (say, the
PDF::API2::Chart::Pie::new function or the
@PDF::API2::TrueTypeFont::ISA array), only the last :: counts as a
separator. The rest is just a string. This way, you can create a
Tech::x11 facet, just as a normal root facet, but visually inside of
Tech. Of course, it will be nice to add something as a symbolic link
from the 'x11' entry in 'Tech' to 'Tech::x11'.

> > >   platform: just "laptop" and "embedded"?  Uhm... it's a point of view
> > >         from which I can't see very much, but a point of view I see
> > > 	a reason for
> > well, there's OPIE, which IMHO is different from regular embedded linux
> > and laptop use. You could also add "server-machine" and "desktop" here.
> 
> "server-machine" and "desktop" are tricky, as someone would like to have
> openoffice in his servers (ugh!) and apache in his desktop PC.
> 
> Maybe we could ditch platform:: and just use hardware::laptop and
> hardware::embedded.
> 
> About "desktop", I'd leave it to be handled in a special facet/namespace
> handled by the debian-desktop people.

I don't like platform - I thought of 'programs meant to a specific
platform', and using Debian's definition of platform, we would
probably end up with very small collections - lilo and plex86 would be
under platform::i386, silo and em86 would be under platform::alpha. I
do like this categorization you propose, though, only under a
different name. I don't see the conflict you mention in the first
paragraph of your reply, as someone could surely have OpenOffice in a
server - but it is not an application _meant_ for server use
(unless... there is a way to call it from the command line and ask it
to noninteractively translate a .doc to a .pdf? ;-) ), I do have
Apache on my laptop and desktop machines... But that is a use that
goes out of the common use - Apache is _not_ a desktop package,
OpenOffice is _not_ meant for a server. If you care about what a small
percentage of the users do, why don't you add user::enrico,
user::erich and user::gunnar to the facets and let each one of us add
every package we use under our very own category? :)

> I almost forgot to talk about facets/namespaces that could be maintained by
> corresponding Custom Debian team: I think this'd be so great!

Of course, this is almost natural - I don't really like the tasks we
currently have in Debian. A good collection of tags (or faceted tags)
can make CDD work much better.

Greetings,

-- 
Gunnar Wolf - [email protected] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF