> Tim Churches wrote:
> > Thomas Beale wrote:
> > > I have to agree with Dave here - I see it as problematic if OSHCA
> > > doesn't see interoperability as a key issue. FOSS just gets you
> > > applications and components. Interoperable FOSS gets you integrated,
> > > componentised systems and environments. This is where the cost advantage
> > > of FOSS will be shown in the future. It is worth considering the
> > > ObjectWeb approach (http://www.objectweb.org).
> > <http://www.objectweb.org%29.>
> >
> > No-one has suggested that interoperability is not an important issue for
> > FOSS, although personally I don't regard it as the *only* issue. As with
> I don't think anyone does. Functionality, performance, security, safety,
> economic viability, maintainability etc are things we are already
> interested in.
Indeed, as well as more "human" aspects of FOSS projects such as
community, training and support resources and so on. But none of these
are mentioned in the current OSHCA constitution. Hence I don't see why
"interoperability" - which would need to be defined because it means
different things to different people - should get a special mention.
> > nearly everything, there are costs as well a benefits associated with
> > building interoperability into software, and these have to be weighed
> > and judgements made about what to do and when, given the inevitably
> > finite resources and time available to any particular project.
> true, to an extent, and yet it is this kind of thinking that I think
> leads too many efforts to make the default position one where
> interoperability is not part of the product, but will be thought about
> later. There are two problems with this. Firstly, interoperability can
> really only be designed in at the beginning. Secondly, if there is no
> interoperability, there is no re-use.
Hmmm, that is not categorically true. The most common mechanism for both
re-use and interoperability between FOSS applications is wrapping the
API of one application or system to make it available for use in
another. That happens all the time for languages such as Python: someone
creates a wrapper around a C library to expose its interfaces to Python.
Typically, the C library was never written with integration in Python in
mind, and oftn the result is an ugly but functional interface, or
sometimes an extra layer is added to make the interface more "Pythonic".
But all of this happens as an afterthought - the C libraries are very
rarely written with Python in mind - and they typically are wrapped for
use in Ruby, TCL and other dynamic languages as well.
Take the CHITS example. AFAIK, it was not written with any set of
interoperable interfaces in mind (at least not ones which Dave Forslund
would approve of). It is desirable to make CHITS interoperate with our
NetEpi Analysis (NEA) data analysis tool, which also doesn't have
automated application interfaces. Despite that, we will achieve our
goal, entirely post-hoc, by sitting down for a day or two and writing
some interface code in PHP and Python. Problem will be solved, I get to
meet and work with Alvin and colleagues in Manila and will no doubt
hatch plans for further collaboration, re-use and interoperability.
That's still a valid approach, in my view, as a stepping stone to having
the machines talk amongst themselves entirely automatically.
> What I am really talking about here is not how to better design a
> product, I am talking about engendering a culture of intoperability
> among FOSS producers, with the aim of making sufficient interfaces, data
> specifications, knowledge models etc published so that the default
> decisions when building something new are:
> * re-use existing components (because now I can see the APIs published
> online, I can use them directly)
> * only build things that are not already built (with the existing
> "ecosystem" of tools and products mapped out, I can see what is missing,
> what is available)
> * use design approaches already in use; try to fit into available paradigms
>
> I am advocating that a culture of re-use and interoperability be adopted
> in health FOSS.
Sure. But I suspect that there is already much more of that going on
than might first be apparent, particularly re-use of lower-level tools
and components at the software re-engineering level. I can't think of a
single health-related FOSS project that has written its own operating
system, or its own database management system, or its own programming
language and associated libraries, for example.
> A community like OSHCA could help this, in a similar way
> as ObjectWeb does for middleware, by providing the informational and
> collaborative framework of the software ecosystem.
Yes, very useful things for OSHCA to do.
Tim C
YAHOO! GROUPS LINKS
- Visit your group "openhealth" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
