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