[REBOL] Rugby: Stub code optimization ...
From: petr:krenzelok:trz:cz at: 22-Nov-2001 12:35
Hi Maarten and list,
just an idea/enhancement request -
->> size? %huh.txt
>> length? compress read %huh.txt
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 ....
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 [...][...])
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
... and then one function to let client "complete/build" stubs on the
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?
-------------------------- 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.
- 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 ...