[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dents-list
Subject:    Re: DENTS: update on lots of stuff
From:       Paul Kunysch <illume () gmx ! net>
Date:       1999-08-17 7:33:10
[Download RAW message or body]

"Todd" == Todd Graham Lewis <tlewis@mindspring.net> writes:

 Hello


Guile is the GNU-way to turn your application into a interpreter in
order to make it modular and customizable. It's not a language, it's
not a CORBA-replacement, it's not easier (for me) than C, it just an
interpreter-environment.


Todd> I would really like to see a guile driver of some sorts.  I'm by
[see below in this mail]

>> 2. Emacs-design

Todd> I have to admit that I am a skeptic of this approach.  Tying
Todd> yourself to a given language is a bad idea, regardless of how

Guile is not "one" language. Right now Guile can "translate" Scheme,
TCL and a C-like syntax. The websites say that Python might be next,
but you can even add a XML-like syntax yourself, if you really want to
confuse our users. :-)

(I didn't test how this works, but I think that it can be done.)


Todd> cool the language.  Better to use something like CORBA to export
Todd> functionality in a language-independent way.

I don't see where Guile and CORBA overlap in function. CORBA is
something I didn't even touch in my "emacs-like" vision.

[emacs-design]
Todd> Ok, reality check.  A scheme driver, where you have scheme code
Todd> answering queries for given zones, would be cool.  Unless there
Todd> are some pretty damned convincing arguments that I haven't
Todd> though of, any more extensive use of scheme than that just ain't
Todd> going to happen any time soon.

If we implement this driver correctly there's no reason to use our
outdated drivers anymore. Let's review our current modules:

Why do we need a "mod_frl"-subdirectory if it's a matter of perhaps
ten scheme-lines for the "sanity check" and a scheme function to
calculate the needed results.

If we have this driver we don't need "mod_XYsql" anymore. The guile
developers have a special mailinglist dedicated to design a unified
database-interface which could be used by generic sql-modules.  Why
should we do additional work if we don't have to?

The guile-website hasn't a high opinion of perl-syntax so that some
C-functions might be necessary for "mod_perl". But I doubt that we can
make a perl interface as simple as the other languages (callbacks!)
so it won't be used much.

I suppose that it's possible to explain the stddb-syntax to guile, but
that's not the only possible solution that would be superior to our
current driver.

I suppose I would handle recursiveness differently.


You said you "really like to see a guile driver of some sorts".  Why
should we keep obsolete concepts if we want to include a better one?

In addition it's not simple to set up the guile-environment in a
module. We might be able to do this, but we gain many advantages if we
_allways_ initialize just one such session for the complete program.

And if we do this we can parse a config-file (or commands recieved
through corba or tcp) and the defined symbols will be available in the
modules, in the core, everywhere.

We don't have to hide any structures.

We get a garbage-collection for the modules.


If these arguments didn't convice you, can you under why they
convinced me?

Todd> We already have a server design plan and a vision for how to
Todd> translate that into a great server.  I don't think that turning
Todd> Dents into Emacs at this point would be a good idea for the
Todd> project.

Either we're not walking in the correct direction or our vision is not
as good as we thought, IMHO. :-/

>> I've continued by writing a scheme-only part: a script that

Todd> Why don't you just use scheme to pass messages out of and into
Todd> the server, along the lines of mod_msg_tgl?

It makes no sense to convert data into a format our drivers
understand. We have to decode and encode a message when we recieve or
send it. It makes no sense to convert them to a binary-format that
will be used nowhere.

Todd> That way you use scheme for what scheme is good at (doing funky
Todd> stuff in a great programming environment) and you use C for what
Todd> C is good at (taking fixed input and doing precise things with
Todd> it.)

I selected this "exercise" _because_ I wanted to see the worst-case.
And I was surprised how easy it was. I still think that decoding is
harder in scheme, but that's not the point.

Todd> I must say, I don't see an advantage to doing your packet
Todd> packing in scheme instead of using the existing routines.

I can't call the existing routines with this as input :

((origin 10)
 (flags query rd)
 (queries (a "www.tu-ilmenau.de." in)))

I like this kind of input and therefore I think it an advantage to
have a function that understands it.

I could have written another function in C, but I wouldn't have
learned how to work with binary data and I already constructed some
SCM-structures from C my the previous "exercise".

>> Someone who wants to use guile-modules won't like the
>> apache-solution.  Someone who hasn't much free memory and doesn't
>> want to do tricky things won't like guile.

Todd> 1) People with that little memory don't use DNS at all.

On "Aug 1" we had a guest named "rend" in #dents and he said that he
loved that dents used less memory than named, IIRC.

You once said that speed is not that important and now you say that we
can afford additional memory. If you're right then your apache-vision
if inferior under all aspects I can think of.

Todd> 2) If you used message-passing, then you could compile your
Todd> scheme scripts to executables using Stalin or some such scheme
Todd> compiler.

Dents won't be a program anymore, it will be an interpreter. The fact
that the code is evaluated at runtime is the main reason why we should
use guile.

Our users should be encouraged to modify our drivers. It would be
possible to specify functions in the initscript/configfile that will
override some default-functions. Even the most stupid admin can test
"his" module interactively, eg.

Todd> Does anyone really care about memory if they're using scripting
Todd> languages?

Of course. That's why people write emacs-lookalikes that have a
limited functionality.

Todd> Perhaps.  I would urge you first to consider what the Emacs
Todd> approach buys you.  To my mind, it doesn't buy you much.

A driver should be as simple as to call a function that checks whether
it's a "handled" request and to add the result if it was valid.
But our current design is much more complicated.

It should be possible to modify a driver without a development
environment. But we can't find a good way between "hidden structures"
and a simple concept.

A driver should build automatically everywhere, including platforms
that don't support shared modules. Someone on the list said there are
no such platforms. Libtool docs list nine platforms where shared
modules aren't possible. I don't want to fix such problems wich are
already solved through libltdl and you don't like libltdl. Picking a
completely different module-systems is an alternative. ;-)

Todd> Contrary to popular belief, the world is not EMACS.  8^) 8^)

Strange that you have to modify a quote from the emacs-docs to tell us
this lies. ;-)



I get the impression that you think of driver-writers as developers
and not as users. :-(


Bye

-- 
Contrary to popular belief, the world is not ASCII.

[prev in list] [next in list] [prev in thread] [next in thread]