What's beyond Rails?
James Toomey
critique of HTML in general. I've done web development with PHP,
ColdFusion, and ASP, and being able to use Ruby in doing so (especially
with Rails' well-designed database interactivity) is certainly a
welcome change. However, the general model is still the same, in terms
of using code to write out HTML to an essentially-static page. The HTML
interface is still such a far cry from the things you can do with a
rich client. For ordering airline tickets on Travelocity or books on
Amazon, the web works great, but imagine trying to emulate Adobe
Photoshop via a web browser, or a spreadsheet like Excel.
It seems to me that there needs to be a next-generation of HTML that
enables web apps to truly be like rich client apps, and
I don't think the solution needs to be a faster connection that sucks
down the entire application in the form of massive Java applets every
time I want to use the program. Perhaps the solution does need to be a
"computer" that's designed from the ground up as a web-enabled dumb
terminal, but that has forms and controls optimized so that they
require minimal data inflow to tell them what to do.
To me, this would make the web incredibly more useful (and would put
serious potential into the claim that Google wants to become a web
operating system). If I've purchased Adobe Photoshop (or rented it, as
I'm sure will be the more likely model), instead of loading it on every
computer I use, why can't I get to Photoshop at any computer in the
world merely by logging into my personal website and getting access to
every software program I own or am renting? Why would it need to be
reloaded at every computer? This is particularly annoying when you're
visiting a friend in another city for a weekend, and jump onto his
computer to check email or show him how to do something useful, and
think, "I wish I had App X loaded on here right now."
I was disappointed to see Google Suggest being touted as innovative; it
seems to indicate that Google's going to stay within the existing web
realm and not try anything really new (as I read on the web somewhere,
"for a web app, Google Suggest is neat; for a desktop app, it's so
1995"). For all of Google's deep pockets and reputation as innovative,
I expected to see them partner up with a hardware manufacturer and try
something dramatically different.
Douglas Livingstone
> Somewhat off-topic rant: This isn't so much a dig at Rails but a
> critique of HTML in general.
That's what Macromedia is trying to sell you!
Flash MX with Flash Communication Server.
It isn't quite fast enough to write photoshop in it, but that's what
people are trying to do.
On the other end, if we could get programmable SGV (imo we need a
"canvas" of some sort to get close to excel apps) there might be
something there, or you could try XBL/XUL of some sort. (I'd love to
be able to do client side Ruby XBL interfaces...)
Douglas
B. K. Oxley (binkley)
> That's what Macromedia is trying to sell you!
What about interpreting XUL in Ruby? A Google search on <<ruby xul>>
does turn up some material. There is this intersting blog post about a
fellow experimenting with Rails + XUL:
http://www.zedshaw.com/blog/programming/ruby_xul.html
Or one could use a YAML version of XUL, I suppose. :)
Cheers,
--binkley
Francis Hwang
pretty crappy interaction-wise, but you can use web apps in a lot more
places. There are lots of efforts to bring more rich interactivity to
web apps: Java, Flash, AJAX, XForms, even Mozilla's XUL might count
depending on how you look at it. There's no clear standard for how to
do these things, so there's a lot of messiness and it might take some
time for everything to get sorted out.
Personally I'm also a little concerned about how highly dynamic sites
push back against other web efforts. AJAX-y sites are hard to make
accessible to the blind, and from what I've seen they tend to break
REST, as well. REST used to be a largely academic concern, but it's
only now that we're starting to pass around URIs as permanent tokens
(technorati, del.icio.us, etc.) and that's a big part of REST. If I
never see another session variable in a URI it'll be too soon ...
Anyway, getting Photoshop in an online app is going to take some doing.
When you're running a gaussian blur on a 2 MB image, you want to be as
close to the metal as possible. You wouldn't want to do that in
Javascript.
p.s. Rich Kilmer's Flash app Alph was supposed to help with this whole
issue, Rich are you still working on it?
Francis Hwang
http://fhwang.net/
Jeffrey Moss
less). SGML is the worst man, but thats what we're stuck with, it aint going
away any time soon.
You share my same vision, of applications like photoshop being written for a
web browser, a subscription model, those are the kind of apps I'm interested
in developing. Use google maps as an example of an innovative application.
Get real good at Javascript.
I have a DHTML version of lemmings bookmarked on my browser at home. Its
pretty impressive for a DHTML only app but it runs slow as hell, for
LEMMINGS! Lemmings ran faster on my old sega game gear as a kid. It's a real
shame we're stuck with this mess of semi-interoperable technologies. Flash
seems to be the best thing to use if you want to write a truly immersive
app, credit goes to the last guy to mention this.
-Jeff
Richard Kilmer
I am working on implementing on open-source set of components in Flash (
http://actionstep.org ). Its a port of Cocoa/NextStep/OpenStep to
ActionScript. Its a big project, but its going to be the focus of my
efforts (in my day job) so IT IS going to advance quickly.
Alph will bridge into this component set (rather than Macromedia's
bug-ridden slow set). If we implement NIBs (serialized user interfaces) and
an Interface Builder type of app, then it would be possible to load a remote
UI and control it from a rails app via Alph...that would be a kick-ass long
term solution for RIAs.
Best,
Rich
Matt Pelletier
being used to do. Much like HTML is now doing things it was never
designed to do. Designers took HTML and starting using it for layouts,
like they were used to with Desktop publishing tools. After the mess of
nested tables and FONT tags, CSS came around and became an elegant
solution. HTTP is being asked to pretend it's not stateless. Fortunately
people have spent a lot of time thinking about this. Unfortunately not
all of the ideas are good.
1. Post-backs
I have wasted plenty of time trying to work around ASP.NET's postback
architecture. For simple apps it indeed will ostensibly work like a
WinForm. For anything moderately complex, you can get into a mess of
issues when designing controls and components. Blech. I think the entire
premise of postbacks is flawed (hopefully I'm not naively soured just by
MS's implementation). Rather, relying on a postback paradigm to mimic
statefulness is flawed.
2. Ajax
Ah, asynchronous requests, in-page, you say? Beautiful. No more posting
back (at least not continuously)? Great. I can see the faces of a
thousand web developers as they anxiously got their invite to gmail
(back before they were being given away in wheelbarrows), and watched in
awe as the 'view source' command produced not much more than a gigantic
javascript library. We've since seen other things like Google maps, and
Tada list, and so on. Beyond giant companies dedicating teams of people
for specific apps like Google does, I expect RoR to be the 'platform'
pushing the envelope with this.
Unfortunately, Javascript is not going to be doing Photoshop-like work
anytime soon.
3. RIA
Macromedia has been pushing what it calls 'Rich Internet Applications'.
The idea is simple. 99% of browsers have Flash installed, with PLENTY of
spare CPU cycles to do the graphics work. Flash can make asynchronous
calls like Ajax's HTTPXmlRequest.
Recent versions of Flash (MX, MX 2004) have moved in the direction of
App development, with form controls, theming, and more powerful
ActionScript. You can either write directly in Actionscript, or you can
also use it's developer IDE Flex to write in an XML spec Macromedia
developed (cleverly dubbed MXML). The RIA platform is setup like so
(correct me if I'm wrong here): You get Flex Server running, and develop
RIAs using MXML (MacromediaXML), and Flex server turns them into Flash
forms. Neat. It's still maturing, but I think ultimately it's quite
promising.
Macromedia even has a desktop wrapper for flash RIA apps called Central.
You can download modules like a weather checker, etc. It sort of has an
OS X Expose widget look about it. It's a resource pig and it's slow, but
again, so was (er.. is) Java. That's what happens when you build your
own graphics layer.
4. Dumb Terminals / Thin Clients
This one has been tried again and again and there's no great solution.
Microsoft released a version of Windows for thin clients. IBM dumped a
ton of money into this. Ultimately people don't want to have just thin
clients. They want a hard drive, music, etc. Google's ability to make
cheap server farms is just as important as their ability to make
searches effective. I wouldn't rule them out from trying anything right
now, but I don't think they're after desktop software like photoshop.
Their position seems to be that the overall paradigm has changed from
desktop-run to Internet run. Just read Paul Graham's 'The Other Road
Ahead').
http://www.paulgraham.com/road.html
So what comes after? I don't know. HTTP is an inherently flawed way to
use the Internet if you want desktop-like apps like photoshop, but the
web has such saturation that people have and will continue to try to
make it work.
Luke Renn
> The underlying issue is that HTTP was never designed to do what it is
> being used to do. Much like HTML is now doing things it was never
> designed to do. Designers took HTML and starting using it for layouts,
I've been real impressed with the mozilla framework. I wonder if
anyone has gotten around to writing ruby binding yet. I'm suprised
more application aren't written using it to be honest.
--
Luke | PGP: 0xFBE7D8AF
gose...@comcast.net | 2A44 9EB2 F541 C1F2 D969 56E3 8617 5B7F FBE7 D8AF
Curt Hibbs
> * Matt Pelletier <pelle...@eastmedia.net> [2005-04-14 05:38:56 +0900]:
>
>
>>The underlying issue is that HTTP was never designed to do what it is
>>being used to do. Much like HTML is now doing things it was never
>>designed to do. Designers took HTML and starting using it for layouts,
>
>
> I've been real impressed with the mozilla framework. I wonder if
> anyone has gotten around to writing ruby binding yet. I'm suprised
> more application aren't written using it to be honest.
It was started, but it has not been active for a couple years. From what
I recall, it was to the point where you could write XPCOM components in
Ruby. What was still needed was to be able to use Ruby along with
JavaScript in handling the XUL UI scripting.
Curt
Juraci Krohling Costa
1 Result found: myWebOs.com <http://myWebOs.com>
Does somebody remembers something about mywebos.com <http://mywebos.com>? It
was a project to develop an "entire" OS web-based. Obviously, you still
needs a "real OS" to boot, but everything was on myWebOs: spreasheets,
"word" documents, email client, etc etc etc. I don't know when exactly they
were gone, and where exactly they stopped, but that was a great idea.
Some URL's that I found on google, to make sure I'm not nuts =)
http://www.xent.com/nov99/0465.html
http://www.pcworld.com/news/article/0,aid,14077,00.asp
regards,
juca
On 4/13/05, Matt Pelletier <pelle...@eastmedia.net> wrote:
>
> The underlying issue is that HTTP was never designed to do what it is
> being used to do. Much like HTML is now doing things it was never
> designed to do. Designers took HTML and starting using it for layouts,
> like they were used to with Desktop publishing tools. After the mess of
> nested tables and FONT tags, CSS came around and became an elegant
> solution. HTTP is being asked to pretend it's not stateless. Fortunately
> people have spent a lot of time thinking about this. Unfortunately not
> all of the ideas are good.
>
> 1. Post-backs
> I have wasted plenty of time trying to work around ASP.NET<http://ASP.NET>'s
--
juraci krohling costa
http://jkcosta.info
Ezra Zygmuntowicz
write your front end in flash and use ruby on the server instead of
macromedia's proprietary communication server. amf stands for action
message format and its a binary format used to ferry objects back and
forth between actionscript and ruby. You can pass just params or arrays
or hashes but the coolest thing is you can basically instantiate your
server side ruby objects in actionscript and call methods on them from
flash. It's pretty cool because of the flexibility of flash interfaces.
It's not going to let you write server side photoshop any time soon but
its a huge leap forward as far as interfaces go above html.
-Ezra
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
509-577-7732
ez...@yakima-herald.com
Francis Hwang
On Apr 13, 2005, at 4:38 PM, Matt Pelletier wrote:
> 1. Post-backs
> I have wasted plenty of time trying to work around ASP.NET's postback
> architecture. For simple apps it indeed will ostensibly work like a
> WinForm. For anything moderately complex, you can get into a mess of
> issues when designing controls and components. Blech. I think the
> entire premise of postbacks is flawed (hopefully I'm not naively
> soured just by MS's implementation). Rather, relying on a postback
> paradigm to mimic statefulness is flawed.
For those of us who don't know, care to post a quick explanation of
what a post-back is? I Googled it but only got a bunch of ASP.NET
pages. And if I'm gonna read about Microsoft APIs, somebody better be
paying me.
Francis Hwang
http://fhwang.net/
Peter Suk
> You could take a peek at amf4r. It's on the raa. This lib lets you
> write your front end in flash and use ruby on the server instead of
> macromedia's proprietary communication server. amf stands for action
> message format and its a binary format used to ferry objects back and
> forth between actionscript and ruby. You can pass just params or
> arrays or hashes but the coolest thing is you can basically
> instantiate your server side ruby objects in actionscript and call
> methods on them from flash. It's pretty cool because of the
> flexibility of flash interfaces. It's not going to let you write
> server side photoshop any time soon but its a huge leap forward as far
> as interfaces go above html.
What would be really cool would be a way for a server-side Ruby program
to instantiate Flash GUIs. (Maybe written as a TK emulation.)
--Peter
--
There's neither heaven nor hell, save what we grant ourselves.
There's neither fairness nor justice, save what we grant each other.
James Britt
>
> For those of us who don't know, care to post a quick explanation of what
> a post-back is? I Googled it but only got a bunch of ASP.NET pages. And
> if I'm gonna read about Microsoft APIs, somebody better be paying me.
I take it you either do not use the XmmlHttpRequest object, or are paid
to read about it?
:)
Actually, from poking around MSDN, I get the sense that postbacks are
mix of XMlHtppRequest calls (or the like) and DHTML. Client-side form
objects send HTTP posts back to the server, where request handlers reply
with some data, and the page is then updated. Remote scripting, again.
James
James Britt
> On Apr 13, 2005, at 4:18 PM, Ezra Zygmuntowicz wrote:
>
>> You could take a peek at amf4r. It's on the raa. This lib lets you
>> write your front end in flash and use ruby on the server instead of
>> macromedia's proprietary communication server. amf stands for action
>> message format and its a binary format used to ferry objects back and
>> forth between actionscript and ruby. You can pass just params or
>> arrays or hashes but the coolest thing is you can basically
>> instantiate your server side ruby objects in actionscript and call
>> methods on them from flash. It's pretty cool because of the
>> flexibility of flash interfaces. It's not going to let you write
>> server side photoshop any time soon but its a huge leap forward as far
>> as interfaces go above html.
>
>
> What would be really cool would be a way for a server-side Ruby program
> to instantiate Flash GUIs. (Maybe written as a TK emulation.)
I believe this thread has already mentioned the Alph project. And you
could use Laszlo with Ruby.
James
--
http://www.ruby-doc.org
http://www.rubyxml.com
http://catapult.rubyforge.com
http://orbjson.rubyforge.com
http://ooo4r.rubyforge.com
http://www.jamesbritt.com
Mark Roseman
> What would be really cool would be a way for a server-side Ruby program
> to instantiate Flash GUIs. (Maybe written as a TK emulation.)
Yes, this would be great!
A while back I did a similar thing, using Tcl (with a Tk emulation
layer) on the server to create and drive a Java applet GUI. Worked very
well for what it did, but would be nicer to see the client piece done in
Flash instead of Java for all kinds of reasons.
For the curious, there's an old paper about it (the work itself wasn't
open source) at http://www.markroseman.com/pubs/proxytk.pdf.
Mark
Matt Pelletier
Postbacks do not, unfortunately, use XMLHttpRequest (comment to James)
Postback allows you to treat form controls similarly to those in desktop
apps, in that they appear to maintain 'state'. Say you're on a shipping
address page, with a country dropdown and province dropdown. When you
change the country dropdown, you want it to load the provinces in that
country.
Barring the obvious alternatives in this simple example (AJAX, JS
preloading, etc.), the form has to go back to the server to get the new
list of provinces, but you want to do this without losing the 'state' of
the page (which mostly means the current state/value of all the controls
in the page), or force unecessary trips to the database for dynamic data
on the page that is not affected (i.e. a shopping cart list). So when
you change the country, the 'onchange' event triggers a javascript
function that submits the form. ASP.NET will read in this POSTed form,
determine what you were trying to do (which I explain below), do it,
then send the page back with the state restored, minus the changes
caused by your action (new provinces in the dropdown).
ASP.NET is able to maintain state by storing a 'snapshot' of the initial
page state (when it was first sent to you based on an HTTP GET). This
snapshot is just a hidden input with an encoded, concatenated set of
name/value pairs, called the PostBackData. When a control triggers the
page to post back, ASP.NET will recognize it is doing so, and will read
in that page's PostBackData field. It uses this to determine what it
sent to you BEFORE you changed any fields. It then reads in the CURRENT
values from the POST variables, allowing it to see what is different
(the country field changed). Then, for any control that changed, it
raises an event. This is where you can do your magic and tell it to
affect the *new* resulting state (in this case different provinces).
Right before it sends you the new page, it takes a new snapshot and
stores it in the same PostBackData field. Continuity.
The value for this technique is less obvious when you're dealing with
simple forms (by this point even firefox remembers text fields and
checkbox fields for you). It's more useful when dealing with things that
technically are not form fields, such as a table of data that was
generated by one of ASP.NET's WebControls (i.e. the shopping cart). If
you're changing the country dropdown, you don't want ASP.NET to go and
pull the rest of the database-driven data fields all over again (i.e. if
you keep a shopping cart list stored in one of these). Saving yourself a
database trip is nice, but beside the point. The main idea is that the
PostBackData's hidden input value tells ASP.NET what the page looked
like BEFORE it posted back. And, since it's looking at this BECAUSE it
posted back, it can compare them and take action based on the difference.
I hope I've explained this clearly.
Generally speaking, Postback is a good idea, and it works, but I don't
think it's necessarily the most elegant solution to maintaining state.
The postback string can get very long, and overall it's a band-aid to a
larger problem (statelessness).
Incidentally, there is a postback generator for RoR, by Tobias Leuke,
which I have not looked at.
http://wiki.rubyonrails.com/rails/show/Generators
There is a good explanation of ASP.NET's Postback here. This is by far
the most straightforward explanation I've ever read (and I've read
plenty), and even here it seems like a big hassle to deal with.
http://www.15seconds.com/issue/020102.htm
Matt
Stephen Haberman
> Actually, from poking around MSDN, I get the sense that
> postbacks are mix of XMlHtppRequest calls (or the like)
> and DHTML.
Microsoft does have some docs on remote scripting, but "postback" in ASP.NET
terminology has nothing to do with Ajax technologies.
In ASP.NET, "postback" means someone GETs a page and then POSTs the form
back to the same page. It simply means the user has POSTed back to the same
page they were just viewing.
The purpose (or perhaps just a side effect), is that ASP.NET can then
serialize the page object's state into a hidden form field behind the
scenes.
1) A user GETs FooPage.aspx, an HTML file with ASP.NET markup, that also has
a FooPage.cs "codebehind" .NET class with relevent business/display logic,
etc.
2) FooPage.cs does some stuff and can put anything it wants to keep/persist
into this ViewState hash table
3) FooPage.html is written out to the browser - and the ViewState hash table
is base64 encoded into a hidden HTML form field
4) User does some stuff and hits submit to POST back into FooPage.html
5) ASP.NET sees the hidden HTML form field, and says "oh, this is a
postback!", and deserializes it into the ViewState for the request's
instance of FooPage.cs
So, summarizing, postback allows ASP.NET to have this magic ViewState hash
table that persists across requests, not via a session, but by riding along
in the HTML.
ASP.NET developers frequently do "super.isPostBack()" (or is it
"base.isPostBack()"? -- too many languages) calls in their Page_OnLoad
method to tell whether their ViewState is brand new and they should do
initialization and put stuff in it, or if it already has stuff in it from
the previous request.
Also, just FYI, on the few ASP.NET projects I've done I've found the
ViewState/postback stuff to be pretty slick. Its pretty well hidden behind
the scenes. And from what I've seen, successfully leveraged by a whole lot
of their built-in ASP.NET controls/widgets/etc. That being said, I didn't do
anything too complicated, so given the original posters frustrations with
postback, it seems like YMMV.
- Stephen
James Britt
> Here goes.
>
> Postbacks do not, unfortunately, use XMLHttpRequest (comment to James)
Ah.
> ...
> I hope I've explained this clearly.
Yes. Yow.
>
> Generally speaking, Postback is a good idea, and it works, but I don't
> think it's necessarily the most elegant solution to maintaining state.
> The postback string can get very long, and overall it's a band-aid to a
> larger problem (statelessness).
Indeed, and it seems the sort of thing that encourages poor Web app
design because it masks certain difficulties.
> There is a good explanation of ASP.NET's Postback here. This is by far
> the most straightforward explanation I've ever read (and I've read
> plenty), and even here it seems like a big hassle to deal with.
>
> http://www.15seconds.com/issue/020102.htm
Thanks for the explanation.
James
James Britt
>>Actually, from poking around MSDN, I get the sense that
>>postbacks are mix of XMlHtppRequest calls (or the like)
>>and DHTML.
>
>
> Microsoft does have some docs on remote scripting, but "postback" in ASP.NET
> terminology has nothing to do with Ajax technologies.
>
> In ASP.NET, "postback" means someone GETs a page and then POSTs the form
> back to the same page. It simply means the user has POSTed back to the same
> page they were just viewing.
>
> The purpose (or perhaps just a side effect), is that ASP.NET can then
> serialize the page object's state into a hidden form field behind the
> scenes.
<snip/>
Thanks for the explanation. This is handy to know if I ever get around
to more C#/ASP.net coding.
James
Jonas Hartmann
> Somewhat off-topic rant: This isn't so much a dig at Rails but a
> critique of HTML in general. I've done web development with PHP,
> ColdFusion, and ASP, and being able to use Ruby in doing so (especially
> with Rails' well-designed database interactivity) is certainly a
> welcome change. However, the general model is still the same, in terms
> of using code to write out HTML to an essentially-static page.
> The HTML interface is still such a far cry from the things you can do with a
> rich client.
The internet is a network of information. You can pretty well
distribute information with hyperlinked text.
You can critize the kind of how HTML is made but not in this way.
Rich interfaces require users to work a lot with them, to learn to use
them. Simple, so mostly easy to use interfaces dont.
Text is black, Links are blue, that is simple, and if there is a good
hypertext "author" behind that, it works very well. (See Wikipedia or
DMoz)
> For ordering airline tickets on Travelocity or books on
> Amazon, the web works great
This is already an extension to the basic "task" of the web.
FORMs let the normal user put in some information back onto the network.
> but imagine trying to emulate Adobe
> Photoshop via a web browser, or a spreadsheet like Excel.
First of all, why should I?
> It seems to me that there needs to be a next-generation of HTML that
> enables web apps to truly be like rich client apps,
There is SVG, but I don't see the need.
> and
> I don't think the solution needs to be a faster connection that sucks
> down the entire application in the form of massive Java applets every
> time I want to use the program.
Massive flash applets - god how I like flash-click-to-play Firefox
extensions. Gone, all the trash that burns my eyes.
> Perhaps the solution does need to be a
> "computer" that's designed from the ground up as a web-enabled dumb
> terminal, but that has forms and controls optimized so that they
> require minimal data inflow to tell them what to do.
Now what do you want? Rich User Interfaces? Or Simple, easy ones? I
don't get you now?
> To me, this would make the web incredibly more useful (and would put
> serious potential into the claim that Google wants to become a web
> operating system).
Web What? DMoz / Wikipedia / Leo ... > Google.
And IF, then Apache ( :-) + Internet Explorer is the "OS of the Web" :-(
> If I've purchased Adobe Photoshop (or rented it, as
> I'm sure will be the more likely model),
OMG even more rental things :<
> instead of loading it on every
> computer I use, why can't I get to Photoshop at any computer in the
> world merely by logging into my personal website and getting access to
> every software program I own or am renting?
why would I want to rent software. if I am forced to use close
software I am already dependent enough on the manufacterer.
> Why would it need to be
> reloaded at every computer? This is particularly annoying when you're
> visiting a friend in another city for a weekend, and jump onto his
> computer to check email or show him how to do something useful, and
> think, "I wish I had App X loaded on here right now."
Get a notebook. (I can recommend 12" a iBook G4 =)
> I was disappointed to see Google Suggest being touted as innovative; it
> seems to indicate that Google's going to stay within the existing web
> realm and not try anything really new (as I read on the web somewhere,
> "for a web app, Google Suggest is neat; for a desktop app, it's so
> 1995"). For all of Google's deep pockets and reputation as innovative,
> I expected to see them partner up with a hardware manufacturer and try
> something dramatically different.
I can't figure out what you want to say.
About HTML. Basically there are features missing in regards to forms.
You cant have "float values" in forms (no sliders, knobs or anything),
you cant do sliders with steppings (fixed value steps) and some of
these things need you to create workarounds.
Worst of all is that there is no interactivity without javascript -
what a pain.
xul is a nice approach but works only on GRE (gecko runtime engine)
atm afaik and yes there is SVG and SMIL - go write a browser (XUL +
ruby renderer ;p) the techniques are mostly there.
anyway I still don't see that there is such big need for these things.
there is still the possibility to use client<->server architectures
with OS native applications written in ruby or other languages
communicating with a server that is on the internet (but not www).
What we do need more is software that let people, everywhere, even
those not to familiar with the web, attach content they have to the
web WITH metadata, and LINKED into logical structures.
And in regards to this, there are some limits, even IF browser
supported current standards, with the current standards cause they do
not offer as many layout features as professional news paper designing
applications do offer. HTML just does not offer enough structure
elements (only 6 levels deep headers?) and CSS does not offer enough
layouting power. (try to have a text with an image floating centered,
vertically and horizontally... I didnt manage that yet =)
what has all this to do with rails or ruby?
zimb...@gmail.com
Look, here is an impressive DHTML GUI framework : http://bindows.net
Demo : http://bindows.net/bindows/samples/applauncher/
Cheers,
... zimba
Peter Fitzgibbons
>
>Peter Suk wrote:
>> On Apr 13, 2005, at 4:18 PM, Ezra Zygmuntowicz wrote:
>>
>>> You could take a peek at amf4r. It's on the raa. This lib lets you
>>> write your front end in flash and use ruby on the server instead of
>>> macromedia's proprietary communication server. amf stands for action
>>> message format and its a binary format used to ferry objects back
and
>>> forth between actionscript and ruby. You can pass just params or
>>> arrays or hashes but the coolest thing is you can basically
>>> instantiate your server side ruby objects in actionscript and call
>>> methods on them from flash. It's pretty cool because of the
>>> flexibility of flash interfaces. It's not going to let you write
>>> server side photoshop any time soon but its a huge leap forward as
>>> far as interfaces go above html.
>>
>>
>> What would be really cool would be a way for a server-side Ruby
>> program to instantiate Flash GUIs. (Maybe written as a TK
emulation.)
>
>I believe this thread has already mentioned the Alph project. And you
could use Laszlo with Ruby.
>
>
>James
>
How would Ruby be used with Laszlo? Jruby? Or only .rhtml as sources
for data?
Thanks.
Peter Fitzgibbons.
James Britt
>
>
> How would Ruby be used with Laszlo? Jruby? Or only .rhtml as sources
> for data?
I *believe* that a Laszlo client just needs to exchange XML messages
with the server, and that can be anything that knows Laszlo XML-speak.
But I've not actually *used* this, so I could be wrong.
James
Bil....@nasa.gov
Francis Hwang wrote:
> REST used to be a largely academic concern,
For those non-web developers (like me) that still
want to follow along, see
http://www.xfront.com/REST-Web-Services.html
for a description of REST (REpresentational State Transfer).
Later,
--
Bil Kleb
http://fun3d.larc.nasa.gov
David A. Black
jason_...@pobox.com
James Toomey wrote:
> Somewhat off-topic rant: This isn't so much a dig at Rails but a
> critique of HTML in general. I've done web development with PHP,
> ColdFusion, and ASP, and being able to use Ruby in doing so
(especially
> with Rails' well-designed database interactivity) is certainly a
> welcome change. However, the general model is still the same, in
terms
HTML
> interface is still such a far cry from the things you can do with a
> Amazon, the web works great, but imagine trying to emulate Adobe
> Photoshop via a web browser, or a spreadsheet like Excel.
> I don't think the solution needs to be a faster connection that sucks
> down the entire application in the form of massive Java applets every
a
> "computer" that's designed from the ground up as a web-enabled dumb
> terminal, but that has forms and controls optimized so that they
> require minimal data inflow to tell them what to do.
> serious potential into the claim that Google wants to become a web
as
> I'm sure will be the more likely model), instead of loading it on
every
> computer I use, why can't I get to Photoshop at any computer in the
> world merely by logging into my personal website and getting access
to
> reloaded at every computer? This is particularly annoying when you're
> visiting a friend in another city for a weekend, and jump onto his
> computer to check email or show him how to do something useful, and
> think, "I wish I had App X loaded on here right now."
Michael Campbell
~>ruby -e 'puts "rails".succ'
railt
Not very sexy, I'll grant you that.
jason_...@pobox.com
1.) You could do photoshop via http.
It may interest you to skim http://opensource.adobe.com/ and realize
that for a couple versions now, photoshop's UI logic has been written
with declairative sublanguages of their own design. It's fairly
straightforward to imagine treating the UI componant as a declariative
document in xml, that specifies logic for preparing computational
transactions that are relayed via http. It's quite accurrate to think
of applications as a giant spreadsheet, where when a cell is notified
it's invalid it dispatches the requests necessary to re-evaluate it's
contents via http post or xmlhttprequest.
The only real barrier to photoshop via http is not http, it's the lack
of a toolkit for the client side portions. Once uppon a time I would
have said there's no high performance client side language, but these
days, I imagine javascript and most browsers html rendering would
actually be fast enough to handle the various graphics rendering tasks
a photoshop like application does.
2.) REST is good.
Statelessness is good. It's not just an annoyance. It's key to why the
web's architecture works so well. Ask yourself why didn't a rich
document format and snazzy browsers get made on top of protocols that
existed at the time, like nttp?
3.) Thick clients and local applications arn't going to go away.
But you will see a transition in that direction, particularly when part
of the applications target usage is communication. S5Presents and the
similar tools are a great example.
4.) So what's next?
I think it's going to be html + javascript. As ugly as that sounds, the
standards process of the web has always been to try to standardize some
sanity after the fact. Pro-active standards making like SVG has yet to
really work. The key is what the browser makers do. And at the moment,
html + javascript is what they do, and I don't foresee that changing
signifigantly for at least 5 years. Flash is the only thing I really
think has a chance of competing. XUL and some of the other things out
there are quite cool on a technical level, and are really better
solutions. But I don't think they can pierce the barrier to entry. Not
unless someone very big forces the issue (read as: Microsoft, US .gov,
etc).
It's a first past the post situation. Html+Javascript made it past the
post. It's a shame that the horse is lame, blind, insane and infested
with fleas, but it's what managed to win.
So for ruby specificly, what I'd like to see personally is some ruby
tools for abstracting over the guts of html + javascript rich clients.
That's certainly no small task. But it's definately what we can see
already happening all over the place. Look at Rails, it gives you
simple ajax without needing to know javascript. Look at ruby web
dialogs. Look at hobix.
Ilmari Heikkinen
On 16.4.2005, at 00:09, jason_...@pobox.com wrote:
> Well, I guess I have a dissenting opinion:
>
> 1.) You could do photoshop via http.
>
> It may interest you to skim http://opensource.adobe.com/ and realize
> that for a couple versions now, photoshop's UI logic has been written
> with declairative sublanguages of their own design. It's fairly
> straightforward to imagine treating the UI componant as a declariative
> document in xml, that specifies logic for preparing computational
> transactions that are relayed via http. It's quite accurrate to think
> of applications as a giant spreadsheet, where when a cell is notified
> it's invalid it dispatches the requests necessary to re-evaluate it's
> contents via http post or xmlhttprequest.
>
> The only real barrier to photoshop via http is not http, it's the lack
> of a toolkit for the client side portions. Once uppon a time I would
> have said there's no high performance client side language, but these
> days, I imagine javascript and most browsers html rendering would
> actually be fast enough to handle the various graphics rendering tasks
> a photoshop like application does.
>
The problem is that there are no high-performance libraries for
javascript to munge image data. To do arbitrary edits to an image in
javascript, you need to use a single div(or somesuch element) per
pixel, and do all the calculation in js. Even when it's a small 640x480
image with a single layer, it's going to be 307200 pixels. And that's
going to be slow going in dhtml. The browsers'll probably blow up at
around hundred thousand elements.
When you can run Quake 1 with software rendering in a 320x240 window
with html + javascript, it'll be about fast enough for Photoshop.
(Maybe there is there a port of q1?)
Maybe if there was a fast VM for javascript and direct rendering access
in DOM...
*shrug* who knows what the future brings :)
jason_...@pobox.com
The pixel munging is done on the server in whatever language you
please. Display of results is done by regenerating results on the
server, which the client refreshes.
The html+javascript is just used as a sort of very bare bones 2d scene
graph, like a stripped down gdi or xwindows.
In other words, very similar to google maps.
Like I said, you can think of it abstractly as a spreadsheet where the
client has all the logic for cell interdependancies, but the heavy
calculations for cell re-evaluation is done by posting and getting to
the server.
Francis Hwang
economically worth it to offer such software as a web service, I wonder
how good your bandwidth would have to be for this to be sensible with
high-definition images.
For example. I've got Photoshop files on my machine that easily top 100
MB in size, but let's just 100 MB as a representative sample. Let's say
I've got that file living in this web app, and I run a one-pixel
gaussian blur on the whole thing. The web client issues the command to
the server, the server churns on this for a few seconds, and sends the
whole image down the pipe again ... My cable modem at home has a peak
downstream of 5 Mpbs, so it's going to take 20 seconds for me to get
the new image -- and that's assuming the app doesn't have to share the
pipe with any other program like BitTorrent or Acquisition, or, hell,
my mail program, which checks my mail every 5 minutes.
Now, you can try to run some lossless compression on the file to try to
get it down to, say, 10 seconds, but that makes everything more complex
and, oh, sometimes you've got high-entropy images so you've gone to all
the trouble for very little gain.
You can also try to serve only the view of the image that the user
needs right that instant, but that doesn't so much kill the lag as
spread it around. The monitor I use at home, for example, is a 1280x960
resolution with 24-bit color, which means, if my math is right, that
filling my screen requires 3.5 MB worth of pixels. It takes me 0.7
seconds to download that much data if my cable modem's doing well. That
doesn't sound like so much until you realize you have to have that wait
every single time you zoom in or out, or scroll up or down, or even
change the background color from white to transparent. This is similar
to the problem faced by online FPS engines: Since you can't rely on
subsecond response times when you're playing CounterStrike over the
network, the server has to give the client more information than
strictly necessary and trust it to do what's right until the next time
contact is established.
And by the way, if you're dealing with 24-bit images on an app driven
by HTTP+JavaScript, how good is the color fidelity going to be?
I'm happy to do plenty of things on the web, but image processing ain't
one of them.
Francis Hwang
http://fhwang.net/
jason_...@pobox.com
The web client issues the command to the server, the server churns on
this for a few seconds, and sends the
whole image down the pipe again ...
<<<
Still the wrong model. If you were providing Photoshop as a web
application, presumibly you'd be providing storage on the server
itself.
So after your guassian blur filter runs, the app only need to send you
back a ~1000x1000 pixel image that reflects the portion of the image in
display.
If you've worked Satori you can understand how non-destructive editing
with a transaction log works. Your interactions create a log of actions
to complete, and the view is computed on demand... but the entire
calculation need not be done at the full resolution for the entire
file. Logging the actions and generating a preview is sufficient. After
editing is complete and it comes time to save results, then you can
render the transactions at the output resolution.
>>>
That
doesn't sound like so much until you realize you have to have that wait
every single time you zoom in or out, or scroll up or down, or even
change the background color from white to transparent.
<<<
Once again, there's no reason to assume our client is brainless. Much
like google maps maintains a tile cache, we could maintain a cache of
layered tilings. Of course it's not going to be as responsive as
communication on a local machine.
My point is merely that http itself is not the limitation.
>>>This is similar
to the problem faced by online FPS engines: Since you can't rely on
subsecond response times when you're playing CounterStrike over the
network, the server has to give the client more information than
strictly necessary and trust it to do what's right until the next time
contact is established.
<<<
While that's true for modems, it's not necessarily true once you get to
broadband. This is a complex topic with a lot of details. I happen to
have a friend who works professionally in this area. I've played
versions of quake3 that remove all prediction and run at a locked 60hz
rate both for client side graphics and network state update. Latency
isn't necessarily the same as throughput, and human beings are
surprisingly tolerant of latency. You can hit up citeseer for the
relevant basic research done by the .gov in the initial military
simulation days: the net result is that humans can tolerate as much as
150ms of local lag, and that at around 50ms of local lag human
observers begin to have trouble distinguishing between lagged and
unlagged input.
50ms round trip is possible on broadband these days, though not assured
coast to coast in the US or anything.
Anyhow, the point is not weither it's a good idea to do PS as a web
app. I think it's a miserible idea. The point is that html+javascript
rendering is sufficiently fast to serve as the basic drawing layer of a
GUI abstraction. Of course something purpose designed for it would be
better, but with the possible exception of flash, I don't think
anything is going to get enough market penetration: html+javascript are
good enough (barely).
Francis Hwang
On Apr 16, 2005, at 2:49 AM, jason_...@pobox.com wrote:
> Still the wrong model. If you were providing Photoshop as a web
> application, presumibly you'd be providing storage on the server
> itself.
>
> So after your guassian blur filter runs, the app only need to send you
> back a ~1000x1000 pixel image that reflects the portion of the image in
> display.
Okay, but that portion itself represents a significant enough time lag
to cause a serious problem for the person who relies on Photoshop to
get work done. A 1000x1000 image, at 24-bit color, is about a 2.9 MB
image. My downstream is 5 Mbps which means that under peak conditions
it takes about 0.48 seconds to download the view. Not the entire image,
just the view itself.
Also, 1 million pixels is a fairly conservative estimate for the size
of the view you have to deal with. On a full-screen image on my paltry
17" monitor that's about what I get. Apple's 30-inch cinema display
gives you 4 times that many pixels.
I guess the point I'm trying to make is that although it's easy for me
to see certain apps move to web-land, Photoshop isn't one of them. When
you're a serious Photoshop user, everything you do sloshes around a lot
of data, so the network itself becomes an obstacle, and until you solve
the last-mile bandwidth problem you can't deliver something like this
as a web app to the home user.
>>>> This is similar
> to the problem faced by online FPS engines: Since you can't rely on
> subsecond response times when you're playing CounterStrike over the
> network, the server has to give the client more information than
> strictly necessary and trust it to do what's right until the next time
> contact is established.
> <<<
>
> While that's true for modems, it's not necessarily true once you get to
> broadband. This is a complex topic with a lot of details. I happen to
> have a friend who works professionally in this area. I've played
> versions of quake3 that remove all prediction and run at a locked 60hz
> rate both for client side graphics and network state update. Latency
> isn't necessarily the same as throughput, and human beings are
> surprisingly tolerant of latency. You can hit up citeseer for the
> relevant basic research done by the .gov in the initial military
> simulation days: the net result is that humans can tolerate as much as
> 150ms of local lag, and that at around 50ms of local lag human
> observers begin to have trouble distinguishing between lagged and
> unlagged input.
>
> 50ms round trip is possible on broadband these days, though not assured
> coast to coast in the US or anything.
Maybe you know more about this than I do, but how much data does a FPS
have to send out and receive, anyway? It's been my impression that a
FPS server sets a lot of the original model when the game sets up, and
then sends the clients a continuous stream of location and status
updates. I imagine the size of these updates is measurable in bytes or
kilobytes.
> Anyhow, the point is not weither it's a good idea to do PS as a web
> app. I think it's a miserible idea. The point is that html+javascript
> rendering is sufficiently fast to serve as the basic drawing layer of a
> GUI abstraction. Of course something purpose designed for it would be
> better, but with the possible exception of flash, I don't think
> anything is going to get enough market penetration: html+javascript are
> good enough (barely).
>
Yeah, I agree with you there. Applications like Google Maps make the
case for a lot of really astounding web apps, possible in the
near-term.
Francis Hwang
http://fhwang.net/
Bill Kelly
>
> On Apr 16, 2005, at 2:49 AM, jason_...@pobox.com wrote:
> > Still the wrong model. If you were providing Photoshop as a web
> > application, presumibly you'd be providing storage on the server
> > itself.
> >
> > So after your guassian blur filter runs, the app only need to send you
> > back a ~1000x1000 pixel image that reflects the portion of the image in
> > display.
>
> Okay, but that portion itself represents a significant enough time lag
> to cause a serious problem for the person who relies on Photoshop to
> get work done. A 1000x1000 image, at 24-bit color, is about a 2.9 MB
> image. My downstream is 5 Mbps which means that under peak conditions
> it takes about 0.48 seconds to download the view. Not the entire image,
> just the view itself.
That's 5 mega bits, not bytes right? So more like 4.6 seconds,
at full speed?
With the right kind of compression, could send a lot less data.
[...]
> >>>> This is similar
> > to the problem faced by online FPS engines: Since you can't rely on
> > subsecond response times when you're playing CounterStrike over the
> > network, the server has to give the client more information than
> > strictly necessary and trust it to do what's right until the next time
> > contact is established.
> > <<<
> >
> > While that's true for modems, it's not necessarily true once you get to
> > broadband. This is a complex topic with a lot of details. I happen to
> > have a friend who works professionally in this area. I've played
> > versions of quake3 that remove all prediction and run at a locked 60hz
> > rate both for client side graphics and network state update. Latency
> > isn't necessarily the same as throughput, and human beings are
> > surprisingly tolerant of latency. You can hit up citeseer for the
> > relevant basic research done by the .gov in the initial military
> > simulation days: the net result is that humans can tolerate as much as
> > 150ms of local lag, and that at around 50ms of local lag human
> > observers begin to have trouble distinguishing between lagged and
> > unlagged input.
> >
> > 50ms round trip is possible on broadband these days, though not assured
> > coast to coast in the US or anything.
Regarding, "and human beings are surprisingly tolerant of latency",
it's hard to express how funny this is in the context of games like
quake. On the one hand it's true the game is quite playable with
and order-of-magnitude difference in latency between players. But,
oh, the griping, whining, and complaining that ensues! :)
Here are the round-trip ping times for everyone connected to my
quake2 server at the moment (in milliseconds):
29 Raditz
43 ompa
56 Ponzicar
58 SKULL CRUSHER
59 [EF] 1NUT
66 p33p33
67 HyDr0
70 HamBurGeR
74 iJaD
93 Lucky{MOD}
140 ToxicMonkey^MZC
145 Krazy
164 nastyman
171 Bellial
242 mcdougall_2
372 Demon
In a game like quake, you can feel the difference in latency
all the way down to LAN speeds. A couple players, not playing
at the moment, live near the server and even have sub-20
millisecond pings! Which is pretty close to LAN, but
experienced players still report having to adjust their play
style between 20 msec (lives near the server) and <10 msec
(LAN play) latency.
> [...] how much data does a FPS
> have to send out and receive, anyway? It's been my impression that a
> FPS server sets a lot of the original model when the game sets up, and
> then sends the clients a continuous stream of location and status
> updates. I imagine the size of these updates is measurable in bytes or
> kilobytes.
Quake2 data rate for broadband players is in the range of
8 to 15 kbytes per second.
... In a desperate attempt to say something on-topic:
I use ruby to write all my quake2 admin scripts.
I haven't tried Rails yet. The other night I was able
to write a server-status CGI script from scratch in a
couple hours, including spawning multiple threads to
poll all servers concurrently. (So amazingly easy in
ruby.)
http://tastyspleen.net/quake/servers/list.cgi
I considered trying Rails but had no need for a
database to be involved. . . . Someday I'll try Rails
- maybe to keep track of all players high scores
across all game levels.
OK not quite on-topic... I tried <grin>
Regards,
Bill
Tom Copeland
> ... In a desperate attempt to say something on-topic:
> I use ruby to write all my quake2 admin scripts.
First person shooters are _always_ on topic :-)
Yours,
tom
Peter Fitzgibbons
Shoot...
Quake 2 requires admin?!?!?!
Peter J. Fitzgibbons
Applications Manager
Lakewood Homes - "The American Dream Builder"(r)
Peter.Fi...@Lakewoodhomes.net
(847) 884-8800
Bill Kelly
>
> From one who used first-person-shooters to do only one thing...
> Shoot...
>
> Quake 2 requires admin?!?!?!
:)
Primarily along the lines of keeping cheaters off. It
seems to take live human admins to keep the server free
from auto-aimers, speedhackers, etc. etc.
We use the ruby program http://rubyforge.org/projects/dorkbuster/
to give a team of volunteer admins a control room from
which to monitor the server and coordinate their anti-
cheat efforts.
Nothing too fancy, but there are a couple screenshots in
the files section.
Regards,
Bill
jason_...@pobox.com
Maybe you know more about this than I do, but how much data does a FPS
have to send out and receive, anyway?
<<<
Well, the theoretical limit is always just input itself. Mose skew is
often within single byte values, but even if you bumped it up to 16bit
in x,y you're at 4 bits per sample. Within the sample we might have an
upper bound of 10 key up/down events, so figure something like 16 bytes
per input timeslice. The server can simply act as a relay for this
data.
So the lower limit is something like 16 * numplayers * hz. In other
words, you pay more for UPD packet headers.
For reason of cheat protection, few games use this model however (chris
taylor is the only person I know who's a real big fan of it).
It's more common for games to instead simulate on the server and then
stream the state onto the client. The quake engines themsevles went
back and forth on the details of this, but eventually settled on simply
streaming serially id'd state deltas from the server which the client
acknowledges. The server stores a sync point for each client, and
journals the simulation state from the point of last acknowledgement.
Each client can have it's own rate, and the server sends a cummulative
update from the sync point to the current server state. The real cost
of this model is memory, which is why quake3 won't scale to 100's of
players. There's also disadvantages to it's failure mode: the size of a
future packet grows as packets are dropped. But, a client can get back
in sync with a single such packet, so it proves itself fairly robust.
If you read the literature, you can see the quake3 model + the client
extrapolation code is very close to a well known optimistic discrete
event simulation algorithm (timewarp).
Interestingly, in the many models the guy I know has played with, one
that works the best is instead bucketing state slices to be the same
for all clients, and echos the previous state with each state it sends.
Ie sending A, AB, BC, CD. Single packet drops are almost never noticed.
Loss of sync greater than a single slice are handled out of band by the
same code that handles a player jumping into the middle of a simulation
state. It's far less memory demanding, so it scales quite well, and in
practice ends up being quite competative with the quake3 model.
It's been a while since I looked at the actual rates, but you I do
recall that when I'd lock up counterstrike to send input at 60hz and
request server frames at 60hz it'd end up at around 2kbyte/sec download
nominal, with bursts up to mabye 6kbyte/sec in rare moments. Input
upload is always miniscule.
jason_...@pobox.com
Regarding, "and human beings are surprisingly tolerant of latency",
it's hard to express how funny this is in the context of games like
quake.
<<<
Well, don't get me started, but quake's net code has some signifgant
implimentation and algorithmic issues, particularly quake3's prediction
handling. One of the things I took away from the darpa papers I skimmed
is that what humans really sense isn't just the absolute latency, the
variance matters as well. If you give someone a consistant local lag
they stop noticing it quite quickly. But if you factor in prediction to
the control system it starts becoming complicated quickly. Suddenly the
delay factor the brain has to anticpate is changing depending on
several different factors that are outside your awareness.
Someone used to have some java apps up where you could play with this
stuff yourself. It's quite interesting... a similar experience to doing
blind testing of audio equipment... a little uncomfortible when you
have some of your assumptions challanged.
Bill Kelly
>
> Well, don't get me started, but quake's net code has some signifgant
> implimentation and algorithmic issues, particularly quake3's prediction
> handling. One of the things I took away from the darpa papers I skimmed
> is that what humans really sense isn't just the absolute latency, the
> variance matters as well. If you give someone a consistant local lag
> they stop noticing it quite quickly. But if you factor in prediction to
> the control system it starts becoming complicated quickly. Suddenly the
> delay factor the brain has to anticpate is changing depending on
> several different factors that are outside your awareness.
>
> Someone used to have some java apps up where you could play with this
> stuff yourself. It's quite interesting... a similar experience to doing
> blind testing of audio equipment... a little uncomfortible when you
> have some of your assumptions challanged.
I haven't read the darpa papers; sounds interesting. However,
I don't think that the hypothesis that humans can get used to
a consistent local lag--which I completely agree with--tells
the whole story in a hyper real-time environment like quake.
Quake2 seems to do a good job providing a consistent local lag,
provided there's no packet loss. (Q2 doesn't handle packet
loss very smoothly.) I've played quake2 online pretty much
daily for seven years. The part of the story I think isn't
being told by humans being able to stop noticing consistent
local lag, is that the more latency you have--even if you're
used to it--the harder it is to beat players with low latency
connections.
It's fun when we get to see a player who's been on dialup for
seven years finally switch to broadband. It's rare to have
such an extreme example as we had with a player a couple
months ago. He was very skilled, and it turned out he lives
near the server. So he'd been playing quake2 on dialup for
seven years, was utterly adjusted to compensating for the
dialup lag (200+ milliseconds). He was skilled enough to
sometimes beat good players with low-latency connections.
Recently he got DSL, and has one of the lowest pings on the
server now (about 20 msec.) It took him a few weeks to
adjust. Now he just cleans up - he's now one of the top few
players on the server (each of whom has exceptional skills
and low latency.)
It's rare to get such a pure demonstration of how latency
is a handicap to even the most skilled players who've had
years to adjust to it. Our brains may do well at adjusting
to lag so that we stop noticing it, but we don't seem to
be able to truly compensate for it in a way that puts us on
an even playing field against non-lagged players.
(Ob. ruby: Here's a routine that'll work from the command
line or as a require'd file that will query a quake2 server
for its status - including the ping times of all the players
connected, or send remote console commands to the server if
you have the rcon password.
http://tastyspleen.net/quake/servers/q2cmd-rb.txt
E.g. q2cmd tastyspleen.net 27910 status )
Regards,
Bill