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

[REBOL] Re: ANN: rugby 4.3

From: petr:krenzelok:trz:cz at: 21-Nov-2001 15:54

wooohooo, well, let's dig into it ... Maarten Koopmans wrote:
> Hi all, > > I just released Rugby 4.3 , the best version ever. All upgrade! > > Download it at http://www.rebolforces.com/~erebol/ > > Rugby is a rebol request broker that allows you to build distributed > computing applications in a few lines of code! A great example is Graham's > GoRim.
Yes, it is. However, let's prove we are right. I don't call GoRim a success yet, nor do I call RIM a success. I think that polling aproach for instant chat is the wrong way to go. I don't say Rugby is bad architecture, as it is not and it has its future with Rebol! However - does its transport mechanism allow us to build something more real-time, in quality level of IRC? Does IRC use polling? Why should XYZ users contact/poll server each N secs, if there is no message available? Now - would it be possible to build another scenario using Rugby? Frank showed us with his IRC client, that communication using Rebol CAN be really instant. We currently can - - call remote function (via imported stubs,or directly remotely) - call remote function /deffered - is connection closed here? - call remote function /oneway - is connection closed here? - call remote function /wait-for-result - does this block whole user interface, till we don't receive answer? What about following: - chat client running rugby client and server. - chat client connects to server - server registers client's listening ports, and connects to it, keeps the connection * - once message arrives to server, it distributes it to all client channels ... *But probably, we've got problem with firewalls here ... It's not critique, just reality - I showed GoRim to several friends, and typica answer was - why is it so slow in response? What is your opinion on the subject?
> > What's new: > > - Transparent error propagation. An error on the server is now serialized and > instantiated on the client as the same error! This makes it easy to do > distributed debugging. >
Be carefull with error ;-) I pasted Graham one error message, which showed whole path in my system on my server. I call it a security risk :-)
> - Http server side handler is improved in the way it clears the buffers at > the end of a request. This may (or may not) fix the runaway problem after a > long period of time where servers start eating CPU time on some platforms. >
great!
> - Functions now support refinements! YES! > > - Totally renewed stub generation engine for refinement support. As a side > effect you can now import multiple services in the global namespace. > > - Some minor performance improvements compared to 4.3e resulting in a 7-10% > increase overall. > > I will add extra documentation in the next few weeks, although the current > documentation should be good enough for most of you. Please don't hesitate to > ask me questions by email as specfied on the web site. >
Everything great! -pekr-