[REBOL] Re: Rugby: Stub code optimization ...
From: koopmans:itr:ing:nl at: 22-Nov-2001 13:06
> I think that above code speaks for itself. I remember you stating, that
> with http transfer, code compression is not used. Why is it so? Do you
> expect any non-rebol service to read/connect-to Rugby server? It will
> not be able to decode rugby commands anyway. So, few questions here:
> 1) would it be possible to compress even http transfers? Maybe there
> could be some kind of option e.g. http/compressed. Compare those 45KB of
> stubs to just some 2KB of data transferred ....
I agree but.... it is traight forward to use a rugby serve rover http from
java. Using compression breaks it. I'll consider.... What are the votes, my
> 2) some function names tends to be long. Why don't you simply use
> parameters as 'http in form of refinement to given function? Is it
> because you want to save the need to perform some condition inside the
> function? (either http [...][...])
Yes. It is an option = refinement.
> 3) If you will not decide to go with compression method, I looked at
> stubs code and it seems to me that some parts are repetitive. What about
> some kind of object, registering various stubs parts and function names,
> or just maybe not even object, but:
> stb-part1 [source-here (maybe even compressed)] [func-name1 func-name2
The repetition is done to allow multiple servers to be imported in the global
namespace. It is a bit faster as well.
> ... and then one function to let client "complete/build" stubs on the
> client side?
No. The server knows all the details and builds the stubs once. It is a rugby
request for the client to get them. Solves a lot of api changes problems.
> We should think about some optimisations, although Rugby is tiny. Think
> about wireless devices, and suddenly 45kb is not all that small transfer
> ... :-)
> What do you think about it?
You can compress rugby.r it self of course... 2 KB ;-)
> -------------------------- Part 2 - What to use Rugby for?
> Rugby is low-level request broker. I would like to ask, if you thought
> already about its usage in real-life. I mean - building services ...
> Currently we just get-rugby-service ... and, what's next? I mean:
> - some kind of 'help function would be helpfull. E.g. I want to know
> something about services server provides me with. Maybe 'help (or
> 'inspect) could become another "default" function, as 'echo is, - server
> (or client, but function header is changed) would compile function help
> as we know it with rebol.
copy skip first context get-rugby-service tcp://whatever:8001
> - what about external world? We have SOAP/UDDI services
> ... eeeh, what do I mean ... we have flat rugby user space - serve
> [func1 func2 func3 ... funcx]. Has anyone already thought about higher
> level (rugby user level) granularity? e.g. ability to import list of
> functions only. We can run messaging and other services, how to isolate
> their functionalities in rugby world? etc., etc., just curious ...
That is a different problem than the middleware itself, hence I don't include
it in Rugby. Seperation of concerns and so on. But you are free to provide
the Rugby service mgt lib ;-)
For the same reason the security libs (touchdown) are implemented on top of
rugby's rexec layer: when I change something deep down there, it propagates
nicely up. For example when I added http transport.