Re: [Gnumed-devel] Where to start with gnumed

[Horst Herb]

On Tue, 25 Feb 2003 11:12 am, Karsten Hilbert wrote:
> BTW, how would authentication work ? I mean, there would be
> one instance of DemographicsServer living on the server
> machine to which the clients connect.

There are a number of approaches to XML-RPC authentication, see
http://jimfl.tensegrity.net/xmlrpc/ as a good RFC on that topic.

In order to keep things simple, for the time being I would leave the 
authentication part out and bolt it on later.
Lundh's simple xml-rpc library that is now standard with Python since version 
2.2 can be extended with some 20-30 lines of python to include basic 
authentication. The Zope people have such as suggestion: 
http://www.zope.org/Members/Amos/XML-RPC

Not to forget: all of KDE is available via XML-RPC; we can use their address 
book, their word processor, their organizer and whatever via XML-RPC just to 
get started

Ah, the wonderful world of components. I am rediscovering the UNIX Nirvana of 
small tools doing one simple job well in our unneccessaruly complex GUI 
world.

> How does one go about storing stuff in the backend ?

Why, the service that is exposed via XML-RPC inetrface handles all the backend 
stuff. Your client simply posts a "SetXXX" to the service.

> How does one get notified about backend updates ?

Trickier, but not unsolvable :-)))
Any service uses gmBackendListener. So, the service knows about the updates 
alright.
In order to establish two-way communication, any server needs to be told how 
to contact the front end - via XML RPC of course.

I propose a "xcDispatcher" service that lives in front end application space. 
This service can thus use gmDispatcher directly. (ordinary gmXXX module with 
bolted-on XML-RPC interface)
Now, each frontend module that communicates with a service and expects update 
messages from this service "subscribes" to these updates by telling the 
service the URL of it's xcDispatcher.
Service gets update via backend protocol ('LISTEN') -> Service checks whether 
any client has registered a dispatcher for this -> Service does a RPC to the 
xcDispatcher (now Service is an XML-RPC client instead of a server, for a 
change ;-) ) -> xcDispatcher notifies client

May sound convoluted and slow, but since we are dealing with very few expected 
messages from any one backend, it will not impact on performance at all.

For now, just ignore this issue as well (unles it itches you to implement 
right away). This is so simple to bolt on when we need it, should not prevent 
us from getting started.

For now, I'd recommend to quickly read 
http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html
followed by visiting http://xmlrpc.com/,
and if anything remains unclear, there is always an excellent O'Reilly book on 
this topic ;-)

Horst