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

"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > We need a textbased filetype build file as well.
> Same here. Of course we need some non-attribute-based format to be 
> able 
> to control the files via CVS, but I don't think, it needs to be text-
> based. Resource files would be a very natural choice -- currently we 
> have QuickRes and can edit them relatively comfortable (BTW, we, at 
> least I, don't plan to implement the private API QuickRes uses, so it 
> won't run on OBOS; Prefs team: hint, hint ;-). A conversion tool 
> should 
> be easy to do.

Text based resource files have the big advantage that you get CVS diffs 
which you can actually use, and see what has changed.
Also, Be had such tools (beres, and deres), but they are not available 
in source form; an explanation of the grammar used there can most 
likely be found on your hard disk:
file:///boot/develop/tools/experimental/QuickRes/Grammar.html

I think we should have something similar.

> > I usually roll my eyes at any suggestions to use XML
> > for all and everything, but perhaps this is a suitable 
> > case for it?   Would it be overkill?
> Yep. I haven't had a look what XML parsers are available for BeOS for 
> quite a while. Last time I did, there were basically only libxmlparse 
> and XercesC. The former has some incompatibilities with the standard, 
> and the latter is a fat and slow monster with an ugly API.

It's overkill for now, I agree. But in the future, we may want to have 
an XML Kit as part of our distribution; it would be the natural choice, 
then.
AFAIK the B.E.OS people are already working on such a kit, perhaps we 
can work together with them and also include it in our tree (note, I am 
also sceptical about XML everywhere, but it has some advantages :-)).

> > I don't know about resources, but for filetype database
> > entries we could simply go with a bunch of setmime 
> > Bash scripts. The whole lot being built by Jam?  
> > (not sure how it all fits together)
> setmime modifies the MIME database of the host system. What we 
> actually 
> want, is to create a new database somewhere in the `distro' 
> directory.

That would be really nice, and that would ease the maintenance of this 
database - we may want to have a two-way conversion, so that we can 
simply use the FileTypes application to change it, though.
BTW there is a small utility called "mar" which is able to convert 
flattened BMessages, attributes, and resources to (kind of) XML and 
back. We may want to have a look at that one, and extend it to our 
needs (should also be in the standard distro, I guess).

> Moreover you had to convince Tyler, who has already implemented 
> almost 
> the complete MIME support (only some small high-level functionality 
> needs to be finished), to rewrite the basic storage parts. ;-)

Apart from that, I don't see the point in changing the architecture - 
BeOS *has* attributes, so why shouldn't we make use of them? Even if 
the rest of world (blindly exaggerating here) don't know about them, 
they are the more mature way of doing things like this.

> Well, I suspect, that building the MIME database from whatever input 
> files we choose (unless it's XML maybe) won't take more than a few 
> seconds. Compared to some thirty minutes -- or how long a complete 
> build currently takes -- this is really not a big deal.

Right, also, we don't have to build it everytime, only if there were 
changes. And a big MIME type database also has some value in itself, so 
we should provide a way to let other interested parties access it.

> Mmh, compared to other teams, like the kernel or the IK team, this 
> team 
> would really be a tiny one, wouldn't it?

It really shouldn't be a team, but we should have a maintainer for it 
(and other stuff as well). It may not be needed right now, but I think 
we should aim for having one person to talk to for anything MIME type 
database related.

Adios...
   Axel.

Other related posts: