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

Rugby: Stub code optimization ...

 [1/5] from: ammonjohnson:yah:oo at: 22-Nov-2001 17:36


I am not a current Rugby user, but I will need a similar solution soon, BUT I am only going to be able to use Rugby if I can compress the data sent. I don't know how hard it would be to implement, just a thought, but what about making an actual different *tunnel* for compression (i.e. get-rugby-service/compressed which would open a port that compressed all of the communication between server, & client) My 2c Ammon

 [2/5] from: m:koopmans2:chello:nl at: 23-Nov-2001 14:06


Rugby compresses data in TCP transport mode. In http mode it doesn't but nothing stops *you* from doing that on the applicative level. If you need it for http transport in Rugby by default you can patch it with two or three lines. --Maarten *** You wrote once.... I am not a current Rugby user, but I will need a similar solution soon, BUT I am only going to be able to use Rugby if I can compress the data sent. I don't know how hard it would be to implement, just a thought, but what about making an actual different *tunnel* for compression (i.e. get-rugby-service/compressed which would open a port that compressed all of the communication between server, & client) My 2c Ammon

 [3/5] from: petr:krenzelok:trz:cz at: 22-Nov-2001 12:35


Hi Maarten and list, just an idea/enhancement request - ->> size? %huh.txt == 45622
>> length? compress read %huh.txt
== 1547 ->> 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 func-name3] ... and then one function to let client "complete/build" stubs on the client side? 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 ... -pekr-

 [4/5] 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
<<quoted lines omitted: 3>>
> 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? > ---------------------------------------
<<quoted lines omitted: 6>>
> (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

 [5/5] from: petr:krenzelok:trz:cz at: 22-Nov-2001 13:40


Maarten Koopmans wrote:
> > 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
<<quoted lines omitted: 6>>
> I agree but.... it is traight forward to use a rugby serve rover http from > java.
Heh, well, but how? :-) By do get-rugby-service you import stubs to client - what to do with it in Java? Or do you think "rexec"?
> Using compression breaks it. I'll consider.... What are the votes, my > users?
Eh, do you think me and Graham? :-) Well, what about /compressed refinement? The same would go for non-http. Graham told me, that for short messages, compressiong produces worse results, or something like that ...
> > 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. >
No, I probably expressedy myself not clearly enough .... wait-for-secure-result , wait-for-secure-http-result secure-result-available?, secure-http-result-available? get-secure-result , get-http-secure-result It is difficult to remember all that variants ... so I thought of: wait-for-result, wait-for-result/http, wait-for-result/secure, wait-for-result/secure/http. I can imagine that there would be some slowdown by introducing swith, either, or if functions in corresponding functions, but would it be so much? Refinement way is more consistent with rebol and what is more refinement order doesn't matter ... btw: one inconsistency imo ;-): get-rugby-service, get-rugby-service/http, while obove functions would suggest get-rugby-http-service .... What do you think? Even in examples above, you randomly mix secure, http words ... or just introduce /Custom refinement, and provide all refinements in a block ...
> > 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
<<quoted lines omitted: 6>>
> The repetition is done to allow multiple servers to be imported in the global > namespace. It is a bit faster as well.
OK ....
> > ... 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. >
OK
> > > > We should think about some optimisations, although Rugby is tiny. Think
<<quoted lines omitted: 4>>
> > > You can compress rugby.r it self of course... 2 KB ;-)
of course. Frank compresses his IRC client that way - it has 9kb packed, more than 30 kb unpacked ...
> > -------------------------- Part 2 - What to use Rugby for? > > ---------------------------------------
<<quoted lines omitted: 9>>
> > as we know it with rebol. > copy skip first context get-rugby-service tcp://whatever:8001
service users are not necessarily fluent rebol users :-) And that way - you get only function names ...but not built-in function help: ->> print mold first :echo [e /deferred /oneway /http /http-deferred /local tcp-port http-port statement my-spec p1 p2 ref-mode comm r index what-ref rug by-statement rugby-comm] You know now what do I mean? Stub generator destroys inline help imo ... not looked at the code thought :-)
> > - what about external world? We have SOAP/UDDI services > >
<<quoted lines omitted: 7>>
> it in Rugby. Seperation of concerns and so on. But you are free to provide > the Rugby service mgt lib ;-)
:-) everybody knows that I am here to test, complain, complain once more, ask for features, etc. - not to code :-) Cheers, -pekr-

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted