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.