5 Jun
2009
5 Jun
'09
11:27 a.m.
On Freitag, 29. Mai 2009, Jan Janak wrote:
Currently the script directory contains all the database related script,
and some stuff that is not being used much (or at all), i.e. filter_log.sh,
serstats, kam_to_sr.sh.
I think we can use the scripts directory to store supporting scripts that
people typically run once or occasionally.
The tools directory could than be used for all other admin related tools,
such as sercmd, gen_ha1, kamdbctl.
We can also get rid of the utils directory.
Ok, sounds good.
used
I think that xsltproc (or XSLT) is the wrong tool for the job. If you take
a look at the conversion scripts, they use lots of variables, conditional
statements, recursions, and functions specified in the XPath specification.
In other words, we use xlst as a real programming language, but unlike many
other languages available today, it has horrible syntax. Heck, even Perl
scripts are more readable than XSLT.
Hm, i agree that the xpath stuff is really a bit ugly. :-)
[..]
Hi Jan,
sorry for the late reply, i was on vacation.
What about importing them into the tools directly?
do you mean the tools directory? Hm, not sure what then the purpose of
the scripts directory would be, perhaps this could be then removed? > The xml definition of db tables were in db
directory, which now is
> library srdb1(same for ser, are now in srdb2). Do we let them
> there or is another more suitable place for them as they are not
> dependent of
DB
api but
of what DB structure to be used (some modules using db
were moved in common folder already)?
I would suggest that we keep them there for now. The scripts that
are to generate db schema need, in my opinion, an
overhaul, so we might
just
do
it in one go.
I refactored the k XSL scripts (which were imported from SER) in the
last year somewhat and also improved/ added support for DBs!=mysql. They
do IMHO a good job now to generate the needed database scripts from XML
sources, so i don't see a big need to rework them. What i removed was the
possibility to also create insert statements, i think, not sure if this
is needed from SER. [..]
> Another major problem is that the
scripts are not portable. They work with
> xsltproc but would not work with other xsl processors due to subtle
> differences in implementation. I couldn't even generate a consistent output
> across different versions of xsltproc.
Only used xsltproc so far, but i also got the impression that portability
accross different parsers is sometimes a problem.
If I had to write such scripts again, I would have
chosen another language,
probably Python or Perl. They are both wide-spread, they have decent XML
parsers and less terryfing syntax (well, in case of perl this is
questionable
:-).
:-)
With python or perl we could do much more than just
generate plain-text
output, we could create the tables directly in the database, setup
usernames and passwords, handle backups and upgrades conveniently in one
tool, and so on.
While writing those scripts in XSLT was a good experience, I think we are
using the language outside its domain. But at least we learned it, which is
good if one needs to modify the docbook xslt scripts, for example.
I don't would write this stuff against in XSTL either, learning all this was a
interesting experience.. ;-) I only wanted to say that i don't favor a
complete rewrite of this stuff _with the same functionality_ just because it
turned out to be not the perfect choice for the job. The existing
implementation works so far ok, and IMHO there are other, more important
problems right now. If we get more functionality the way i have nothing
against it at all.
Henning