[openbeos] Re: resource files, application signatures, and icons

  • From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Mon, 30 Sep 2002 11:56:10 +0200 (MET DST)

On Mon, 30 Sep 2002, Tyler Dauwalder wrote:

> Resource files: Having a text based format seems like a better idea
> than binary if it's not going to take too much time to get one set up,
> at the very least due to CVS history and ease of browsing/searching.

So let's use beres for the time being, and implement our own beres in the
not so distant future. Our version would also be able to generate
attributes instead of just resources. That way we can use it for the MIME
database generation as well.

[...]
> Resource/Attribute files => distro database: If we want to build a mime
> database to include under distro/, my vote is for using the same
> implementation that the system uses, as it will cut down on the chance
> that some little oversight will cause things to be stored differently
> than expected.

What do you mean by `same implementation that the system uses'? system ==
our MIME system?

> At the moment, OBOS::BMimeType is retargetable, but only at compile
> time (for example, OBOS::BMimeType currently works with a database at
> ~/config/settings/obos_mime instead of ~/config/settings/beos_mime). I
> don't like the idea of making BMimeType itself dynamically
> retargetable, as there are things the database manager in the registrar
> keeps track of that would have to be ignored for calls that weren't
> being made on the actual database; I don't think the overhead is worth
> it for something that's probably only going to be used during our
> build.

As I understand it, the `distro' directory (or actually the respective
platform subdirectory) is a mirror of the to be installed system (i.e.
`/boot'). And thus a MIME database wouldn't actually be there to be used
directly. To use it for testing or whatever, one can as well create a link
to <B_USER_SETTINGS_DIRECTORY>/obos_mime.

> However, it would be reasonably easy for me to make up some
> {get,set}_[whatever_mime_attribute_suits_your_fancy]() functions that
> only read/write data to which you could specify a different database
> location. One could then write a program that simply takes a given
> resource file/attribute file and writes the appropriate information
> into a separate database somewhere under current/distro/.

I would prefer to have the same input file format for resource files and
MIME database attributes. As the majority seems to prefer text files, I
would go with beres' input format. To use dedicated setter functions seems
to rather complicate things. For each attribute you would first have to
analyze what kind of MIME data it is and then call the appropriate
function, while with a generic approach all data that are found would
simply be written to attributes (or resources). Both methods are equally
error-prone, I would say. A well documented input file template should
help to reduce the probability of error significantly.

[...]

CU, Ingo

Other related posts:

  1. Home
  2. haiku
  3. Archive
  4. 09-2002