client-server

[Tyson Dowd]

On 20-Dec-2000, linas@linas.org <linas@linas.org> wrote:
> 
> I beleive the above architecture renders the whole previous
> discussion moot. I also think its a very, very exciting thing to do.
> It solves a number of technical issues, such as multi-user, that
> have been plaguing us.  Next, it give us world-class financial ASP
> capabilites.   Finally, I think this is what microsoft is thinking
> about when it talks .net  and  this alone makes it important for us
> to do this more/better/faster.


I think this approach is very interesting...  I've been looking at the
way these kinds of technologies have been changing lately and I've
noticed three things I think are really cool:

1. XML/SOAP (what Microsoft is calling "web services") to provide
distributed RPC like services.  This does much the same job as CORBA,
but uses technologies that can be re-used elsewhere easily, and so have
a low maintenance cost and a produce a lot of synergy (HTTP and XML).
This can also take out a *lot* of the nastiness of cgi-bin, since you
can just often just request information you want as if you were making a
normal function call (well, ok, perhaps a bit more trouble).

2. XML/HTML with special embedded <objects> that rely on a particular
"plugin" to provide rich functionality.  This is a bit like how Flash
animations or things like that work.
The neat new thing about 2 is that it is increasingly being used in an
inside-out manner, with the web browser being embedded inside an
application, and the application provides the semantics of the <object>
tags.  Of course multiple "applications" can interact to provide
semantics (e.g. gnucash register and guppi).  Even if you aren't using
any external content, the XML/HTML is being used to control the GUI
rendering.

3. Server-side "dumbing-down" of 2 to provide an acceptable interface
for dumb clients.  For example the GUI widgets in Microsoft's
.NET WebForms libraries can be:
(a) downloaded as bytecode to run on .NET runtime, user value changes
are sent to the server using XML/SOAP callbacks
(b) converted to a known set supported by IE 5.5, which turns them into
neat graphical widgets using lots of JScript, sending results back using
some sort of hackery I never really investigated
(c) turned into standard HTML which Netscape can display, returning
results with a standard form.
Since 2 was just XML anyway, this is really just a transformation of XML
-> XML or HTML.  Note that when you do this, you usually have to make a
translation of any XML/SOAP calls you might want to make into cgi-bin
calls.
E.g. add links to the account names, which will generate a new page that
gives a summary of that account.  In a rich client you might retrieve
the summary yourself using SOAP/XML, and not even worry about loading
the rest of the page.

Anyway, I'm sure some of you have seen this stuff already, but I see a
lot of potential in using this kind of technology.
And yes, it is almost exactly what Microsoft mean when they talk about
.NET (although they also throw in a virtual machine for good measure).

XML/HTML is used to unify presentation.
Applications are extensions of the unified presentation technologies.

XML/HTTP/SOAP is used to unify distributed method calls and data transfer.
Services are extensions of data transfer technologies -- providing
content is one kind of service, but there are others (authentication,
backup, synchronization, etc).

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd@cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #