gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Horst Herb
Subject: Re: [Gnumed-devel] Where to start with gnumed
Date: Tue, 25 Feb 2003 20:51:12 +0100
User-agent: KMail/1.5

On Tue, 25 Feb 2003 10:20 am, Karsten Hilbert wrote:
> If we encapsulate calls to our database in business objects I
> think we need not worry about how they go about getting the
> data. If XML-RPC is mandated at some point, the business
> object ist changed but the application stays the same.

Yes and no. Of course, the business logic will always exist independently of 
the XML RPC  interface.

BUT:

1.) The *interface* used in the GUI should be the XML-RPC one.

2.) choice of parameters / data types is important with hindsight to making 
the XML RPC protocol efficient.

Thus, eat your heart out implementing whatever you want, but 
- think of adequate data types suitable for XMLRPC
- if you program GUI, use the XML RPC API: what doesn't exist yet (nothing 
exists yet), you simply define. The first who defines gets "right of way"

Example:
Richard wants to implement his social history widget. He needs information 
about identity and profession of that identity.
1.) He writes a module "xcIdentityServer"
2.) He adds to the methods of class xcIdentityServer.Service "GetPerson", 
GetProfession", "SetProfession"
3.) He writes a white paper about it
4.) He submits white paper and xcIdentityServer to CVS
5.) He announces this on the mailing list (If he is wise, he posts a RFC fisrt 
to the list and implments *after * the discussion)

The, Syan wants to implement a diabetes module. He checks the white papes, 
find out that "Identity" is already catered for, but he needs a new clinical 
service for his diabetes data: step 1 to 5 for this, for "identity" he just 
extends Richard's xcIdentityServer as needed *without breaking anything 
Richard did*.

Can you see the benefits?
Instead of directing people around what to do, everybody can grab what's for 
grabs.
Instead of waiting for implementation of x, y or z on the backend  you simply 
implement a dummy service for that and write whatever module you wanted. If 
then nobody extends your dummy, you do it yourself or you cry for help. But 
you don't wait any more.
Instead of implementing it all ourselves, we can share the workload with other 
groups *even if we have different philosophies and programming 
languages/tools* - at least their work gets us going and viceversa, and we 
can always reimplement.

Horst




reply via email to

[Prev in Thread] Current Thread [Next in Thread]