Re: My thoughts on icons and meta-data
- From: Mark Andrew Hulme-Jones <M A Hulme-Jones hw ac uk>
- To: gnome-list gnome org
- Subject: Re: My thoughts on icons and meta-data
- Date: Mon, 27 Apr 1998 16:35:18 +0100
Dwight Hubbard wrote:
>
> Tom Tromey wrote:
> >
> > Tonight I caught up on my Gnome email. In particular I read the
> > entire Icon thread. Anybody who read the whole thing deserves a
> > medal, me included.
> >
> > This is rather long. Sorry about that. Please bear with me.
> >
> [snip]
>
> I think we need some type of combined proposal. Although, there are
> people who do not like the .info file or putting the metainfo in the
> file. There are times when this is needed. Such as when the data will
> be on removeable media and you want the metainfo to go with the files.
>
> On the other hand, .info files or putting the data in the file do not
> work well if you don't have write access to the directory. In this case
> a centralized database or even a directory tree with the metainfo will
> be needed.
>
> I still note, that the only solutions that have solid working
> implementations to date use some variant of the .info file solution or
> special filesystems (Mac/Amiga/OS2).
>
I think the most relevant argument against .info files is that they
cannot be used very well when working on a multi-user system (as is
pointed out above) so whilst I am rather fond of the idea, (being an
ex-amiga user and all) I'd be forced to concede that other than for
shortcuts of some description they are probably of considerably less use
than I might have envisioned (ie next to no use at all without writing
an exceedingly complex meta-data handling mechanism which can deal with
pretty much any of the suggestions which people have put forward). All
this talk of DBMS' left me with the impression that some people were
advocating the use of database servers like Postgres/MySQL, which I have
to say would be an extremely poor idea. My experience of SQL-based DBMS'
on older machines has left me frustrated at the excruciatingly slow
speed so I think using such a mechanism would likely cut off a large
number of people from trying out the Gnome. (Not to mention the fact
that it's horrendous bloat - having to install a pretty large Orb like
Mico is bad enough...)
I was however left thinking when the idea of using the Berkely DB
system. At first I thought that leaving the user with a binary file
(rather than one they could edit with a text editor) was a poor idea,
but the more I consider it, the more I like the idea. It appeals mainly
because it means one large file in the users .gnome directory (or
whatever) rather than several (although the emacs-like suggestion with
#usr#bin#filename sort-of files is the most appealing suggestion of that
sort yet), and also because the Berkely DB system is enough of a
standard that anyone who can read a man page could write some code to
play with it (and probably break it too ;), not to mention the fact that
scripting languages such as Perl and Python support it, so quicky
scripts to go delving inside could be written in minutes... No the more
I think about it, the more certain I am that such a system would be the
way to go, along with .lnk files or the like for the desktop and both
system wide and home directory-based icon repositories (configurable of
course, so you could point the fm at your mate's 20MB icon repository in
their homedir ;)
Of course, I would imagine that a standard distribution would come with
a reasonable system-wide db already set-up
(/usr/local/gnome/gmc/files.db or some such) and any additions which a
user made would be stored in their homedir....
Mark
-- Mark Hulme-Jones <ceemahj@cee.hw.ac.uk> -
http://www.cee.hw.ac.uk/~ceemahj --
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]