[Gd-hackers] koala changes

[Peter Robisch]

Carl wrote:
> This approach makes me feel a bit dirty for some reason.  :-)

Could not be Dylan's macro feature provide a clean solution?


Some macro like  (only a draft!!)

  define configurated-http-server (server)
    port := 8001;  // optional
    xml-rpc-enabled? := #t;
    register-url('/foo', my-responder);
    register-xml-rpc-method("blah", blah);
  end define http-server-configuration

  let server = make(<configurated-http-server>)
  start-server(server); // returns immediately. optionally waits.
    

Pet-ro 
 

-----Ursprüngliche Nachricht-----
Von: gd-hackers-bounces at gwydiondylan.org
[mailto:gd-hackers-bounces at gwydiondylan.org] Im Auftrag von Carl Gay
Gesendet: Donnerstag, 18. Januar 2007 17:15
An: gd-hackers
Betreff: [Gd-hackers] koala changes

I've started refactoring some of the koala code to make it more easily
usable as a library.  Andreas and I talked (very) briefly about it the
other day but I want to run some of my ideas by everyone for comments.

Basically I want people to be able to use it as easily as they can use
an HTTP server in Python.  Like this:

let server = make(<http-server>);
server.port := 8001;  // optional
server.xml-rpc-enabled? := #t;
register-url(server, '/foo', my-responder);
register-xml-rpc-method(server, "blah", blah);
start-server(server); // returns immediately. optionally waits.
...

This brings up the possibility that one exe will run multiple servers,
which means a lot of Koala's globals have to be moved into a
configuration object of some sort.  That's a good thing anyway, but
I'm not sure the best way to go about it.

I started to have a separate <server-configuration> class to store all
the configurable data, but that has two drawbacks:

(1) the startup sequence (above) gets a little more complex:
let config = make(<http-server-configuration>);
load-config(config, "filename");
config.port := 8001;  // optional
config.xml-rpc-enabled? := #t;
register-url(config, '/foo', my-responder);
register-xml-rpc-method(config, "blah", blah);
let server = make(<http-server>, config: config);
start-server(server); // returns immediately. optionally waits.

(2) it gets unwieldy to either have to pass the config object around
throughout the code or constantly dig it out of the server object,
especially given that I probably don't want to use a really short slot
name like "config".

So now I'm thinking that I'll just make <http-server> be a subclass of
the existing <server> class and it will hold all the config data while
<server> will just be non-configurable core server stuff.  (Plus I'll
move out the statistics that are kept in <server> into some other
class.)  This approach makes me feel a bit dirty for some reason.  :-)
 Basically my question is, do you see a better way to design it or is
this okay?

-Carl
-- 
Gd-hackers mailing list
Gd-hackers at gwydiondylan.org
https://www.opendylan.org/mailman/listinfo/gd-hackers