[REBOL] Re: Rugby: Stub code optimization ...
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
> > 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.
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
> > 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.
>
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
> > 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 ;-)
>
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?
> > ---------------------------------------
> >
> > 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
>
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
> >
> > ... 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 ;-)
:-) everybody knows that I am here to test, complain, complain once more, ask for
features, etc. - not to code :-)
Cheers,
-pekr-
