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

Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> 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.

Although it would be a bit misnamed in this case, I think that's a good 
idea, and helps to prevent spending too much time on it.
The grammar already allows for this, you just had to replace "resource" 
with "attr", and you're done.
But I think we should also consider dropping beres/deres compatibility 
and go the XML route, even with a built-in XML parser, i.e. expat 
(almost free license), or rxp (GPL) - at least that should be the 
easiest and fastest way.

> [...]
> > 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?

I guess using the same implementation to actually write the attributes 
to the files; to be consistent with that implementation, and also 
account for every change that might be done.
But...

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

.. I think that's the better solution. Write out a good specification 
for the the MIME type attributes, and there shouldn't be any problems.
If someone needs to change this spec, he needs to change both; the text 
format, and the implementation - they are tightly tied together.

BTW I was thinking about moving the icons to other files, independent 
from the MIME type files, to ease switching to a different icon set, 
but it could make synchronization between the two databases a little 
nightmare (not sure about it, though).
Perhaps it would be easier to have an icon set, that can be applied to 
the MIME type database, if needed.

Adios...
   Axel.

Other related posts: