Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
A web service example

By Dacta in MLP
Thu May 03, 2001 at 03:28:21 PM EST
Tags: Software (all tags)
Software

Many commentators think that webservices are the future of the internet. The idea is for servers to host applications (or parts of applications) and allow client processes to use them via CGI, SOAP or XML-RPC.

Sounds a good idea in theory, but actual examples were hard to find.

Now Sjoerd Visscher has released XML-RPC Spell Check. This is a demo for his XML-RPC client for IE5 and Mozilla.

If you run a supported browser, give it a go. It's a pretty impressive way of writing a browser based app -- no java, no plugins, and yet it is a useful application.


Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o XML-RPC Spell Check
o Also by Dacta


Display: Sort:
A web service example | 25 comments (22 topical, 3 editorial, 0 hidden)
Hey, neat. (3.75 / 4) (#1)
by regeya on Wed May 02, 2001 at 12:03:08 AM EST

I fired up Mozilla, just special for you. :-) And I confirmed it--it will not work under Konqueror v2.2alpha1, at least not while using KHTML. Perhaps once KMOZILLA is perfected (if it ever is) or once Mozilla is more robust (if it indeed happens.)

[ yokelpunk | kuro5hin diary ]

Arrgh (2.00 / 1) (#9)
by regeya on Wed May 02, 2001 at 01:34:44 AM EST

or once Mozilla is more robust (if it indeed happens.)

s/Mozilla/Konqueror/p

[ yokelpunk | kuro5hin diary ]
[ Parent ]

What an underwhelming experience. (4.20 / 5) (#2)
by Carnage4Life on Wed May 02, 2001 at 12:09:56 AM EST

Maybe if I had more of a background on XML-RPC I'd be able to appreciate this but what I saw did not seem like anything worth getting excited over.

If you run a supported browser, give it a go. It's a pretty impressive way of writing a browser based app - no java, no plugins, and yet it is a useful application.

A spellchecker that uses a text box for input can be implemented with existing technologies (any server side language from JSP to PHP or clientside stuff like Javascript). Why is this XML-RPC example something worthy of MLP?

Carnage4Life voted -1 on this article

A solid endorsement to avoid "thin clients.&q (4.37 / 8) (#4)
by Speare on Wed May 02, 2001 at 12:31:19 AM EST

<rant>

The idea of XML-RPC may be interesting for more involved or complex tasks, but this example just reaffirmed my faith that the NetPC or "thin client" is not going to take over the world any time soon.

Alan Cooper, author of About Face: the Essentials of User Interface Design, has built a company around some solid HCI principles. One of his trademarked favorites is "rich visual modeless feedback."

  • rich: lots of detail available
  • visual: color, shape, layout, size
  • modeless: always there, no interruptions
  • feedback: make the user know what the machine is doing
Why should every keystroke go to the server, just to edit a little text? Microsoft Word's red squiggles offer rich visual modeless feedback on your spelling errors. Fix any typo whenever you get around to it, without having to select a new mode or paste it into a web form. [I do wish a more subtle color could be chosen, though.]

The web is best for research, communications, status and access. When my immediate task doesn't fall into those areas, I'm glad that Oracle's NetPC or the Compaq Audrey hasn't taken the world by storm.

</rant>
 
[ e d @ e x p l o r a t i . c o m ]

+1, I like it (3.80 / 5) (#5)
by decaf_dude on Wed May 02, 2001 at 12:43:03 AM EST

Spiffy under IE 5.5!

While I have my reservations towards web services (mainly bandwidth concerns, but security is close second), I like the idea since most of my work is on my company's Intranet anyway, where security is pretty much well covered, and with Giga Ethernet backbone bandwidth is a moot issue.

I'd like, though, to vote down the demo's web page - what's up with lime green? :)


--
http://slashdot.org/comments.pl?sid=89158&cid=7713039


On webservices in general (4.55 / 9) (#6)
by Carnage4Life on Wed May 02, 2001 at 12:45:34 AM EST

OK, I reread the site and have a better idea of what the example is supposed to show and here's my more informed opinion

The spell checker application is a poor example of how cool XML-RPC can be because it is does nothing that can't be done on a regular server faster. The thought of sending the entire text of a document as XML (adding more data than necessary) to another server to get it spell checked then returned to my server before displaying it to a client seems to me to be the height of inefficiency especially when there will be multiple servers asking for spellchecks from the spell check server.

Secondly after the Netscape RSS fiasco I am not that enthusiastic about building applications that are based on the assumption that some web server I have no control over will be up 24/7/365.

A better example of for XML-RPC would be querying domain specific information from one or more sources that I cannot implement myself. The ever popular stock quotes example is one such application. For example, if there were 3 different XML-RPC servers that served up a) stock quotes based on certain criteria b.) news based on search criteria and c.) URLs for the websites of certain companies, then it would be possible to build a server based app that tied it all together by being a unified interface that provides stock quotes, recent news and the homepage of a company. What would be cool would be that your application doesn't have any of the data but is simply an aggregator of data for the user and provides access to information from disparate data sources via a unified interface. Much cooler than parsing RDF files.

Not really. (4.75 / 4) (#7)
by skim123 on Wed May 02, 2001 at 12:49:48 AM EST

...but actual examples were hard to find

Actual examples implemented with Microsoft's upcoming ASP.NET are quite easy to find, IMHO. But then again, I guess I know where to look more than most... Anywho, check out these resources:

There are others, too... and expect a ton of them to abound when ASP.NET Beta 2 goes public. For the latest skinny on ASP.NET check out: www.ASP.NET.

Sorta like being gay: you're walking around, you know something's up, you just don't know what it is yet.

future of web: (2.25 / 4) (#8)
by rebelcool on Wed May 02, 2001 at 01:32:13 AM EST

i think the future lies alot with the individual. Back in the 80's and early 90's, there were these things called BBSes that were all the rage (alot of people on here probably know what they are). Generally these were ran by hobbyists, simply because theres wasnt much money to be made from them.

The same is true today.

Humans like communities..the success of slashdot as well as countless others show that communities are probably the most popular sites on the internet.

What's this have to do with BBSes? BBSes were mini-communities ran by individual rather than big corporations. Until recently though, it wasnt feasible for an individual to do this.

Though today, broadband is widely available, making running your own webserver a fairly trivial thing to do. And with things like COG (yes yes, shameless plug), it's pretty easy to setup a community on your own hardware.

I think in the coming years, this concept will get far more popular, as the commercial community really isnt all that profitable.

COG. Build your own community. Free, easy, powerful. Demo site

woah! (3.00 / 6) (#10)
by Shren on Wed May 02, 2001 at 03:02:35 AM EST

I'm impressed...

I'm impressed...

Wait, no I'm not. You can do this with CGI. -1. Go find something impressive.

Thin clients (4.25 / 4) (#12)
by ucblockhead on Wed May 02, 2001 at 10:57:11 AM EST

I have one thing to say about "thin clients":
  • Over the past fifteen years, CPU speeds and memory sizes have followed Moore's law, increasing about 1000-fold.
  • Over that same period, bandwidths have increased 100-fold.
To me, trying to move any application from the client to the server is the height of foolishness. The only reason to want a server is when the server provides access to something the client can't get on its own.

I've yet to see even a proposed application that convinces me otherwise. Certainly not this. As far as I can see, there is almost no advantage for thin clients from a user's perspective, and a whole hell of a lot of disadvantages.

The only reasons I can see that companies are trying to push thin clients have to do with marketting and control.
-----------------------
This is k5. We're all tools - duxup

Re: Thin clients (4.00 / 1) (#13)
by scorbett on Wed May 02, 2001 at 11:13:37 AM EST

The only reasons I can see that companies are trying to push thin clients have to do with marketting and control.
I can think of lots of reasons why thin clients would be desirable that don't have to do with marketing and control. I used to maintain an internal database app that was used by not only everyone in the office, but also all the guys out in the field as well. Trying to co-ordinate upgrades when a new version of the app was released was a nightmare. If this had been set up as a web service, upgrades would be done automagically. Ditto for bug fixes - no one has to re-intall the client software with a newer version because it's all on the server, the only thing running on the client end is a web browser.

The biggest barrier back then (this was a few years ago) was bandwidth, none of our guys in the field had the bandwidth to connect to the server to do all their work, but as you mentioned, bandwidth has increased dramatically in the last few years, so this is becoming less of a barrier.



[ Parent ]

however (none / 0) (#14)
by spacejack on Wed May 02, 2001 at 11:31:18 AM EST

The biggest barrier back then (this was a few years ago) was bandwidth, none of our guys in the field had the bandwidth to connect to the server to do all their work, but as you mentioned, bandwidth has increased dramatically in the last few years, so this is becoming less of a barrier.

Which would also make it easier to upgrade the client software :)

[ Parent ]
Re: however (none / 0) (#17)
by scorbett on Wed May 02, 2001 at 01:35:54 PM EST

Which would also make it easier to upgrade the client software :)
No, that would make it easier to download the client software. Installing it is a whole 'nother matter, especially when some of your guys are barely computer literate. By moving to a thin client system, your guys no longer need to worry about installing/upgrading software, dealing with DLL conflicts, running against the latest libraries, etc. It's all handled for them.

[ Parent ]
It isn't that hard... (none / 0) (#19)
by ucblockhead on Wed May 02, 2001 at 06:03:53 PM EST

It really isn't that hard. I've done it under both OS/2 and Windows and in either case, it just really wasn't that hard.

(For the record, when I did it under OS/2, the only people at the other end were underpaid retail store managers who were usually only a couple years out of high school, and the whole thing was so automated that they didn't even know anything had happened...)


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Fields (none / 0) (#16)
by ucblockhead on Wed May 02, 2001 at 11:52:21 AM EST

If they are "out in the field", does this mean that you only want them to allow access to the data when they have access to the internet?
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Would seem to boil down to (3.00 / 2) (#15)
by spacejack on Wed May 02, 2001 at 11:44:55 AM EST

a caching exercise. Is it more effective to transfer updates only when needed, or do you want to refresh all your data constantly? IMHO, you typically want the former (fatter clients) whenever possible. This requires more disciplined design, but almost always provides a better end-user experience. As with anything however, the situation will dictate the appropriate solution. (Though I must say, it would be nice to have a K5-specific client, wouldn't it? :)

Nice idea. Won't work, though. (4.28 / 7) (#18)
by jd on Wed May 02, 2001 at 04:55:53 PM EST

Thin clients are as dead as the dodo. There =WAS= a reason people stopped using VT-52's and other dumb terminals.

Bottom-line is this. Centralised server systems, with connecting ultra-thin clients place an intense burden on the network, are failure-prone, and have absolutely no redeeming features, whatsoever.

They're failure-prone, because if ANY component fails - network node, server, client - then EVERYTHING fails. It's impossible to make crash-resistant, without spending so much that you'd end up with something so expensive that you might as well have bought the server & software and had the whole lot in your office.

It also places an intense burden on the network, because EVERY transaction needs to be sent, along with all necessary handshaking, error-correction, and assorted other overheads. It really doesn't take much to eat up bandwidth.

(It's also important to note that network loss becomes significant at around 1/3 capacity, for a shared network. As soon as you exceed that, the liklihood of packet collisions and random drops becomes so high that it becomes pointless to continue.)

These considerations, and more, are why people moved from using raw X11 packets, telnet, et al, to such things as RPC, CORBA, PVM, MPI and various proprietary protocols for network connections.

(In -theory-, you shouldn't even need a web browser on your computer. Just run the browser on the web server machine, and redirect the output to your X window. You'll find, as so many have done, that the performance hit vastly exceeds any imaginable benefit.)

But software gets updated so often! Surely, that's a good reason for having thin clients! Nope. You're better off with writing modular code, transferring updated modules on an as-needed basis, and using dlopen (or something similar) to load the modules into some skeletal application manager on your LOCAL machine.

=THIS= is the future, not that web stuff. The ability to do on-the-fly, zero-fuss, zero-intervention automagic maintenance. No worrying about whether something is cached or not. No worrying if a given server is up or not. You run the code, IT takes care of the rest.

Profitable for an extinct bird... (none / 0) (#20)
by axxeman on Wed May 02, 2001 at 09:43:01 PM EST

Actually, SunRays are selling quite nicely...

Being or not being married isn't going to stop bestiality or incest. --- FlightTest
[ Parent ]

So? (none / 0) (#25)
by fluffy grue on Fri May 04, 2001 at 01:20:35 AM EST

SunRays suck.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Example is okay... (2.00 / 1) (#22)
by WWWWolf on Thu May 03, 2001 at 09:08:42 AM EST

...but I don't think "web applications" will fly that well.
"Kiss your browser goodbye: The radical future of media beyond the web"

- Headline of Wired mag article about... uh, something that that ancient civilization of "1997" era called "push". =)

My educated guess is that these over-the-network RPC things will never replace "local" applications fully. Constant network connection isn't exactly 100% certain thing for all uses... "If the Server has a problem, the Company has a problem!" =)

-- Weyfour WWWWolf, a lupine technomancer from the cold north...


It does use Javascript (4.00 / 1) (#23)
by wkearney99 on Thu May 03, 2001 at 04:16:57 PM EST

The page does use JavaScript. But it does not use a plug-in.

It is a good idea. Very nicely done.

But no java (none / 0) (#24)
by sjoerdvisscher on Thu May 03, 2001 at 06:21:32 PM EST

It says 'no java', ie. no Java applets. Java and Javascript are two completely different things.

[ Parent ]
A web service example | 25 comments (22 topical, 3 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!