guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Web development


From: Alejandro Forero Cuervo
Subject: Re: Web development
Date: Tue, 13 Nov 2001 20:51:53 -0500
User-agent: Mutt/1.2.5i

Hey.  :)

    How does [HB] know to load a module?

There are the standard modules, which are ALWAYS loaded at HB's
startup.  Other modules are loaded if HB encounters a `:lib' directive
in the .hb files, causing it to dlopen a shared object for a module
(this happens unless the module had already been loaded, of course).

    > [...] Once this is done, you could have a .scm file with a
    > function for each of the above methods (clean, load and unload
    > are optional)...
    
    And, presumably, a call or data structure of some sort to let you
    know which functions are which, ie (define-hb-module '((init
    mymodule-init-fn)))

This is what the `init' method is for.  It registers information about
the module (such as the bindings of its internal functions to tags).
It does so calling back the C functions provided by HB.  :)

    At the moment, what does it have for guile over CGI other than a
    templating mechanism, then?

Well, I'd expect using HB to be very faster than using Guile under
CGI.

And well, even though there's no explicit initialization function yet,
you can still keep things around across requests.  You just can't have
them properly shutdown/destroyed.  For instance, you could check to
see if something has already been defined and call your initialization
rutine only if it hasn't.

Nothing else I can think of, since the wrappers have not been written.
[This was true when I wrote it but HB changed while I was writing this
mail so... keep reading.]

Each wrapper function should be around 10-15 lines of code ... I will
write them along with some documentation and reply to this message
once I get them done (it won't probably be before next week, I'm very
busy atm).

    Supplementary question: is the parsing recursive, ie can the guile
    output include other modules eg (display "<+hello>")?

Not until the wrappers get written.

Unless you do something (admittedly wrong) as

    :out main
    <+guile-code arg=hello>
    :

    :set (guile.exec) guile-code
    ; lots of code here
    (display (hb-argument hbargs "arg"))
    ; lots of code here
    :

    :set hello
    hey
    :

Note that, given the way HB works, the hello object only gets
"executed" inside the call to hb-argument in the guile-code object,
not in the invocation to guile-code (to change this behaviour you
would do <+guile-code arg=*hello>).

Fixing this (making "hello" visible in "guile-code" even if it's not
specified as an argument) should be as easy as duplicating the
function for hb-argument in the C code and changing the wrapped
function from hb->sym->arg to hb->sym->obj.

Actually, I'm going to fix this right away rather than continue with
my stupid homework about Kant and Carnap and Quine.  ;)

*alt tab*

Okay, there you go, in the CVS version of HB, available at
    <http://sourceforge.net/cvs/?group_id=2201> ,
you can do:

    :out (guile.exec) main
    (display (hb-exec hbargs "<+hello name='alejo'>"))
    :

    :set hello
    hello, <+name>!
    <+info>
    :

    :set (guile.exec) info
    (display "Hey there.")
    :

Making this possible wasn't as easy as I thought it would be (since I
wanted it to be possible to pass parameters to the <+hello> object,
not just have the "hello" object executed).

Now what other wrapper function do you want me to write!  :)

    What happens if there is no width argument [and you call
    (hb-argument hbargs "width")]?

If no width argument was specified when your object was invocated,
hb-argument returns #<undefined> (SCM_UNDEFINED in C).

    Have you considered using <?hb...?> tags, which I think may be
    syntactically cleaner?

Hmm.

Why would they be syntactically cleaner?

This shouldn't be hard to implement, but I am unconvinced.  Convince
me?  :)

    No [, I don't want to disable everything with parameters to
    HB's configure script], the interesting thing about HB is the
    ability to support a multitude of languages at the same time in
    one framework.

Oh, ok.

    What sort of performance figures do you see?

I would expect performance to be pretty okay.

The only bottleneck I can think of is in using TCP/IP sockets to
communicate with the HB Daemon (as opposed to using pipes), which
shouldn't be that important.

I'll see if I get some time next week to make a few benchmarks
comparing the speed of Perl (CGI, mod_perl), Guile (CGI) and HB using
both embedded Guile and Perl (CGI, hbcgifwd, mod_hb and HB Daemon
directly).  I wouldn't expect significative differences caused by the
use of HB (but I would expect significative differences depending on
the particular setup (CGI being slower than mod_hb, for instance).

    [The suggestion of using Squid is] an essential one, as apache
    doesn't seem to cache ProxyPass proxies, which means you are still
    called for every page request.

Right.

I'm not sure what happens when all the pages are dynamical and have
stuff such as access counters or generate statistics (at HB's side),
but your suggestion is very interesting nonetheless. :)

Thanks.

Alejo.
http://bachue.com/alejo

--
The mere formulation of a problem is far more essential than its solution.
      -- Albert Einstein.

$0='!/sfldbi!yjoV0msfQ!sfiupob!utvK'x44;print map{("\e[7m \e[0m",chr ord
(chop$0)-1)[$_].("\n")[++$i%77]}split//,unpack'B*',pack'H*',($F='F'x19).
"F0F3E0607879CC1E0F0F339F3FF399C666733333CCF87F99E6133999999E67CFFCCF3".
"219CC1CCC033E7E660198CCE4E66798303873CCE60F3387$F"#Don't you love Perl?

Attachment: pgpqwlbvfTQ1i.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]