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

Rugby XPi : The next generation

 [1/10] from: m:koopmans2:chello:nl at: 23-Jan-2002 22:02


Hi All, I am currently working on Rugby XPi , the next major version of Rugby. But I need to know some features that you may want. Currently I am building in the following functions: - exec-code: func [ passsword [string!] code [block!]] ; execute code in a running rugby server - functions? [password [string!]] ;returns a list of available functions - profiling [ password [string!] b [logic!]] ;Turns on and of profiling on or off on exposed functions - ping ; Check to see if the server is alive - publish [ password [string!] name [file!] content [block! string!] desc [block! string!]];publish content on this rugby server - get-content [ password [string!] /name n [file!]];get all content or just the named one n - add-friend [password [string!] url [url!]]; Add another rugby server to your friend list - remove-friend [password [string!] url [url!]]; The opposite - search [desc [string! block!]]; Search for content - add-functions [ password [string!] func-list [block!]]; Add functions to a rugby service - remove-functions [password [string!] func-list[block!]]; the opposite - set-password [old [string!]new[string!]] get-rugby-service will always return an object as of the next version The XML-RPC stuff will go final there as well. Various bug fixes, of course... Better docs (volunteers anyone? remarks?) Plus various view/console based utilities, such as a service monitor, a remote console and ...??? I'll also bundle tail-func, contract, erebol and some other stuff as extra utilities. It may take some time, but we'll get there! Many thanks to those that have donated to Rugby development so far and the kind emails of the last few days! Please respond with your comments, so I can make Rugby better! You can find Rugby at http://www.rebolforces.com/~erebol http://www.vrijheid.net --Maarten

 [2/10] from: greggirwin:mindspring at: 23-Jan-2002 15:17


Hi Maarten, I'll have to think about the items you proposed a bit, but I can give you some off-the-cuff thoughts right now. :) First, one of the things I *really* like about Rugby is its simplicity. If things can be implemented outside the core functionality, I would vote for that. Of course, this needs to be balanced with the desire for a simple installation. If we end up with too many components, that wouldn't be a good thing either. Other feature ideas: A couple small test/diagnosis scripts. As you know, our setup was a little odd when I started using Rugby. A little auto-test tool that could tell you if the connections worked, whether stubs could be imported correctly, etc. would be great. A 'restart function for servers? For example, let's say I have a Rugby server running, and it talks to hardware, only the hardware might get wacky and not let me know when things have gone wrong, or maybe I know my app will consume memory over time for some reason. Maybe I can run for a while in these states, but restarting occasionally gives me a clean slate to work from. I'll try to make some time to cook up a couple more sample scripts to go with it. Real life has kicked in with a vengance recently, but I'll try my best. :) Would it also be helpful to have an "architectural overview" or design document for Rugby? --Gregg

 [3/10] from: jason:cunliffe:verizon at: 23-Jan-2002 18:57


> I am currently working on Rugby XPi , the next major version of Rugby. > But I need to know some features that you may want. > > Currently I am building in the following functions:
Hi Maarten ..good news! [snip ..8<..lovely feature list]
> - ping ; Check to see if the server is alive
Seems like rugby XPi ping should have a /bounce or /search refinement. If if does'nt get to the first server it i'll try to go through a list of alternates. Likewise if some threshhold metric is reached on the ping-ed Xpi server it can tell the pinger to go ping some others. The ping table format might include some weighting value of where to go. The weighting could then be adjusted by each node in a rugby network based on hops or some other criteria.. make object! [ r.1: [url weight] r.2: [url weight] etc.. ] Perhaps this doesn't belong inside rubgy itself, and its not strictly 'ping', but I can easily imagine distributed services needing a lot of redundacy support to be trully user friendly, and that means optimizing which this extends to. ./Jason

 [4/10] from: brett:codeconscious at: 24-Jan-2002 11:52


Hi Maarten,
> Currently I am building in the following functions:
I'm guessing exec-code is a straight remote do. Very nice.
> But I need to know some features that you may want.
Currently, as I understand it, when the client imports the stubs it gets everything that the server offers. Might be nice to have some server supported packaging of functions into to different "services". This might be useful for when you want a single rugby listening port to handle very different jobs. For example (this syntax for example only - not a request): get-rugby-service/service tcp://... 'data/address-book get-rugby-service/service tcp://... 'file-locking It's not a high priority for me, just something I thought someone might need.
> Better docs (volunteers anyone? remarks?)
I second Gregg's comment on simplicity. I think that is Rugby's primary asset. It would be nice to have the various features as add-ins. So if you don't need all the management, monitoring support, etc you don't have their overhead. Then again you could possibly make these as "load on first use" so that there is no overhead if they are not used. I'll lend a hand to some documentation. Email me off-list for what you think needs doing and I'll respond with what I think I can do :) Brett.

 [5/10] from: petr:krenzelok:trz:cz at: 24-Jan-2002 6:29


Maarten Koopmans wrote:
> Hi All, > > I am currently working on Rugby XPi , the next major version of Rugby. > But I need to know some features that you may want. > > Currently I am building in the following functions: > > - exec-code: func [ passsword [string!] code [block!]] ; execute code in a > running rugby server >
is it replacement for rexec?
> - functions? [password [string!]] ;returns a list of available functions
function names only? Or function definitions similar to 'help function output, including comments and parameters required?
> - profiling [ password [string!] b [logic!]] ;Turns on and of profiling on > or off on exposed functions
eh, I do not know what the profiling is at all :-)
> - ping ; Check to see if the server is alive > - publish [ password [string!] name [file!] content [block! string!] desc > [block! string!]];publish content on this rugby server
what is this one? What is the difference to below mentioned 'add-function?
> - get-content [ password [string!] /name n [file!]];get all content or just > the named one n > - add-friend [password [string!] url [url!]]; Add another rugby server to > your friend list
... and what does this one mean? Does it mean I can call some yet-another-rugby-server function, performing just call to the rugby server I am connected to (bridge functionality)?
> - remove-friend [password [string!] url [url!]]; The opposite > - search [desc [string! block!]]; Search for content > - add-functions [ password [string!] func-list [block!]]; Add functions to a > rugby service > - remove-functions [password [string!] func-list[block!]]; the opposite > - set-password [old [string!]new[string!]]
set-password [old [string!]new[string!] confirm [string!]] ; :-) - avoiding typos ...
> get-rugby-service will always return an object as of the next version > > The XML-RPC stuff will go final there as well.
And that's something I am not clear about. I remember discussion of adding additional stuff to Rugby. You told me that such stuff should go to user level. What is the point of adding XML-RPC as an transport mechanism directly to Rugby? I want SOAP, someone else will want Jabber protocols etc etc and we will end up with Rugby-installation-on-CD :-) Well - I haven't looked at latest Rugby as I am really not interested in XML-RPC - so - what layer does it live in? Is it in your http layer? If so, we should/could probably modularize here, to let ppl choose, what upper-layer communication mechanism they choose. As I said - we will have to support SOAP one day, if we want to talk to web-services servers ...
> Various bug fixes, of course... > Better docs (volunteers anyone? remarks?)
<<quoted lines omitted: 6>>
> kind emails of the last few days! > Please respond with your comments, so I can make Rugby better!
Compressed retrieval of stubs in both tcp and http layers. GoRIM was example - 47 KB vs. 6KB compressed - will speed-up connection set-up time ... Thanks for continuing Rugby development! -pekr-

 [6/10] from: petr:krenzelok:trz:cz at: 24-Jan-2002 7:06


... also ... what about any search capabilities? Will Rugby use just client - server architecture, or will we be able to create whole rugby based network? Then we would need to have some search capabilities, nodes, etc. stuff. One interesting article here: http://www.neurogrid.net/php/whitepaper.php -pekr-

 [7/10] from: dado::slovkaufring::sk at: 24-Jan-2002 8:09


> > - set-password [old [string!]new[string!]] > > set-password [old [string!]new[string!] confirm [string!]] ; :-) - avoiding > typos ...
This is up to the application on the client side, IMO, but it doesn't mean it can't be implemented in set-password.... J.

 [8/10] from: chalz:earthlink at: 24-Jan-2002 2:40


Wow. From cancelling Rugby to all of this! An inspired man, I dare say! Here's a quick question, though: "XPi"? What's that mean? --Charles

 [9/10] from: chalz:earthlink at: 24-Jan-2002 3:02


> > - functions? [password [string!]] ;returns a list of available functions > > function names only? Or function definitions similar to 'help function
output,
> including comments and parameters required? >
I think that, in this case, it would be preferred to list function names first, maybe a brief (one line) description, with the option of displaying further information for individual functions (or even all). Just that, if you have too many functions, displaying all of the args and comments etc would get far too lengthy. --Charles

 [10/10] from: koopmans:itr:ing:nl at: 24-Jan-2002 10:41


A lengthy reply to all of the suggestions (thanks!) - XPi: eXPerience Internet => refers to the P2P behavior in this Rugby release. Once the core is finished..... - I will need a resource description dialect for searches of services / content. If you have an idea or like to play with parse..... - I am also playing with the idea of a redirect function: called by me, deliver somewhere else. - Adding a better Rugby console is high on my list. I have one without decent history and auto-complete. - Modules seem like a very good idea. This will mean that all other functionality that I add will be in terms of modules. As a side effect, automatic code migration and load balancing will be *very* easy. - I may have to look into better authentication methods than a password. - I may move the XML-RPC stuff out as a seperate, hipe-based, script (hipe is Rugby's HIgh Performance Engine) - I will have to find one or two 'always-on' servers that can act as a gateway to the public Rugby ..... playing field? (any suggestions?) - As for those willing to document: - A good tutorial on using /deferred and asynchronous programming and its pitfalls. - Getting started - Why Rugby? - An architectural overview of - current Rugby - the new features (by me) Once we get to XPi in a month or two, it is time for shameless marketing and publicity (perhaps it is already, I know people from Ruby are looking at Rebol and Rugby). --Maarten

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