-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Elpidio Latorilla wrote: | Hi, | | But I see a problem with each group ( or module developer) freely creating his | own set of RPC API's. | | Technically this is very easy to achieve but we all know that the problem lies | somewhere else (it is not the technology). | Yes, one needs a consensus mechanism to agree upon API's and how they are used.
This was exactly the intent of the OMG's Health Care Domain Task Force. ~ One can argue that the OMG process does not fit well with open source, but one must recognize that David Forslund has done just that with OpenEmed. One could also argue that the OMG technology, however good it is, has been by-passed in the open source world at large. Note that both KDE and Gnome have used OMG's CORBA. But also note that the KDE project left CORBA behind for a lighter weight RPC called DCOP that they then implemented XML-RPC on top of, in other words, web services, the heir apparent to CORBA.
So, what is needed is an international process to agree upon the API's. ~ When looking at the past of such efforts, I find nearly all standards processes flawed in regards to open source, except for the one that the IETF uses. In the classic IETF model, someone proposes (a usually simple) model along with a free reference implementation as a draft model within a working group. Over time, other people implement and extend the draft model and at some point it's agreed to be practically useful and then it get's voted an RFC. That process continues with additions and revisions according to utility.
The IETF process is not perfect, it can be hijacked by commerical interests and result in proposed standards where intellectual property is entangled (but efforts to preclude that are mighty) or where the proposals don't have an open source implementation and no one can test them effectively before approval, or the proposals get so bogged down with the agenda's of various companies that they get too complex to be practical without lot's of money for implementation.
But, it does work well, when it works by starting simple with a free reference implementation and corporate representation is not allowed to dominate.
How to do that in open source health care development?
One really doesn't need to wait for a solution. All it takes is two or more developers deciding to work together and a publication means, which can be as simple as a mailing list. In person meetings, called working sessions can be scheduled in conjunction with other health care meetings the developers involved are likely to want to attend!
I for one am willing to work on such an organization from a process perspective, who wants to work on it from a development perspective? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAxbZCY+HG7UEwVGERArUBAJ9iu6xh4TZ9Inf5qjd0OFP/y2xIMACbBtrG cNALdwKH9m+W1vCJvKVmCaE= =aySO -----END PGP SIGNATURE-----
------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ Care2002-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/care2002-developers
