Re: About the source library

[Joerg Wittenberger <Joerg.Wittenberger@xxxxxxxxx>]

>>>>> "DPM" == Didier PH Martin <martind@xxxxxxxxxxxxx> writes:

DPM> The idea is to try to have three family of modules:

DPM> a) Grove/DOM b) Script engines c) formatting object mappers
DPM> (backbends)

In the past few weeks I considered to start doing virtually exactly
that.  But while I coded some stuff in C++ a few years ago, I decided
not to base that on jade code.  This is for a couple of reasons:

a) probably most important: I tried to understand James code.  I
found that pretty hard for both sgmls (the plain C version) and jade.
It's also not too much documented/commented.

Please get me right: I don't want to say "James wrote lousy stuff".
It's my fault. But he certainly writes a different style than me.

b) From the similarities in the languages I believe that it should be
less hard to create a DSSSL interpreter in Scheme that in C++.

Hence I decided to use Scheme for implementation.

c) There is already at least one scheme *compiler* (bigloo) out there
which supports DSSSL keywords and argument parsing (#!rest and
friends) and such.  Guess that's quite a good base.

d) I found Bigloo's executables to be very fast.

Years ago I, when DSSSL was just a draft coded something jade alike
(sdc), which is coded in Scheme for th most part (mixed with C, bigloo 
makes that very easy).

  I remember my idea to make it a DSSSL processor.  It never came that
  far.  It does not even understand DSSSL, it's merly the engine;
  cutomization is done in scheme code, which resembles what the dsssl
  reader should produce.  This thingy is certainly better at the
  transformation part.  I did linuxdoc support within about 2h by
  coding transformation into another DTD.

I used that since for all my writings.  When I've got jade I was
suprised about it's slow speed and high memory requirements.

I *guess* there is some flaw in jade making it so slow.  At least the
backend interface is a design flaw I can hardly live with.

DPM> A good candidate for module interface is XPCOM. Contrary to
DPM> CORBA, XPCOM has a single binary signature and thus, even if
DPM> modules are created with different compilers, we can have them to
DPM> interface because of this common binary signature. Also, because
DPM> the integration with Mozilla is greatly simplified.  </reply>

I'm currently prototyping and experimenting as well.  I never read
anything about XPCOM - what's that.

I believe that the right way (TM) to do it is to integrate as much as
possible and resonable from any source we can find.  But even more
important is to come up with a clean and promising, *written* design.

I think there are many things to discuss, propose and agree upon.
Not sure that this is the right mailing list for that.  I'm ready to
set up a special one and/or host the cvs repo.  But I think before
doing so, we should continue either here or in private mail.

Unfortunaly I can't compose a more detailed mailing until monday.

Regards

/Jerry
-- 
Sapere Aude


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist