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 ----- Original Message ----- From: "Maarten Koopmans" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 22, 2001 5:06 AM Subject: [REBOL] Re: Rugby: Stub code optimization ... > > > 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 > -- > To unsubscribe from this list, please send an email to > [EMAIL PROTECTED] with "unsubscribe" in the > subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
