11 Nov
2007
11 Nov
'07
12:38 p.m.
About the rbuild proposal:
In my opinion, it's not the right way to go.
From my point of view, the api and status generation
tool (be it a
script or executable written in a common script language like perl,
php, python or C/C++) should parse the source code and gather all
information out of the original files.
It's neither necessary nor smart to store un-synced redundant metadata
in external files about the same.
the parser simply collect the data out of the source files.
I am under the impression that some want to try to add additional
metadata to files like *.rbuild files, just to simplify the parsing
process but on the otherside 'generate' a lot more problems by make it
almost impossible to keep the data in-sync.
From a limited first point of view, it sounds great;
but it reminds me
of one who is new to object oriented world and want to express
everything as object or metadata.
The real world is different, and it's better to keep it simple and let
the parser do its task => parse the source files. Don't get me wrong,
metadata are good and have it's place, but we have to make sure that
we keep the balance and avoid "information"-hell.
So instead of outsource the information (developer, translator,
language-info, etc.) from the source code to external rbuild files,
keep the data in place where it belongs to.
It's the parsers job to parse the source and extract it, and put it
together in a meaningful way (generate static output, be it xml or
html).
And as response to the rbuild package discussion:
The whole discussion about the language and package support has gone
in the wrong direction. It would be already possible to use rbuild xml
files to define the BootCD, LiveCD with some extra work (replace the
bootdata config files, with xml rbuild files and modify some setup
code; or alternative generated the bootdata files based on xml
config).
The main point is that the package information should be stored in a
single directory e.g. boot/bootdata, instead of adding such
information to each module-rbuild-file.
Having a single location, it would be a piece of cake to "fork"
compilation packages (BootCD, LiveCD) and create a custom ISO file by
copy&paste&modify the package xml file.
Of course something for the future, our current solution is fine for now.
Additionally, I would like to point out that the statistics and/or
API-docu tool should work fine on Win32 and Unix and be licensed under
a GPL v2+ compatible license. So that we can put it in place to our
online services (website).
Furthermore, Java and dotNet (C#, VB.Net, F#, etc.) should be avoided
(IMHO) for several reasons (either not-available, or too much overhead
and nowhere included by default; which is pretty much the opposite of
our ReactOS and especially the RosBE philosophy.
Klemens