Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[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 users?
> 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 > func-name3] >
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. --Maarten