Once we have settled on a v1.0 of the spec, it would be great to get some implementations off the ground so that we have feedback for later versions.
What plans are already in the works? In particular, do we have any solid ideas about building a reference implementation? Have we considered building on top of existing work, for example InSTEDD’s Resource Map?
In Uganda, we have a use case of producing a registry server that can help various systems coordinate facility data. This could be a good focal point for collaboration on a reference implementation, in particular because as a standalone service it might also be deployed as part of other, similar systems.
We’re very keen to collaborate if we can, because the whole point of producing a standard is interoperability and reducing duplicated effort.
If you look back through the project documentation you will see that InSteDD’s ResourceMap is already contracted through NetHope to produce a reference implementation. DHIS2 will also produce an implementation (not paid for by NetHope).
The other point of standardising an api is to encourage multiple implementations, extending client choices and combating vendor lock in.
Once we have settled on a v1.0 of the spec, it would be great to get some implementations off the ground so that we have feedback for later versions.
What plans are already in the works? In particular, do we have any solid ideas about building a reference implementation? Have we considered building on top of existing work, for example InSTEDD’s Resource Map?
In Uganda, we have a use case of producing a registry server that can help various systems coordinate facility data. This could be a good focal point for collaboration on a reference implementation, in particular because as a standalone service it might also be deployed as part of other, similar systems.
We’re very keen to collaborate if we can, because the whole point of producing a standard is interoperability and reducing duplicated effort.
If you look back through the project documentation you will see that InSteDD’s ResourceMap is already contracted through NetHope to produce a reference implementation. DHIS2 will also produce an implementation (not paid for by NetHope).
The other point of standardising an api is to encourage multiple implementations, extending client choices and combating vendor lock in.
Once we have settled on a v1.0 of the spec, it would be great to get some implementations off the ground so that we have feedback for later versions.
What plans are already in the works? In particular, do we have any solid ideas about building a reference implementation? Have we considered building on top of existing work, for example InSTEDD’s Resource Map?
In Uganda, we have a use case of producing a registry server that can help various systems coordinate facility data. This could be a good focal point for collaboration on a reference implementation, in particular because as a standalone service it might also be deployed as part of other, similar systems.
We’re very keen to collaborate if we can, because the whole point of producing a standard is interoperability and reducing duplicated effort.
Thanks for the suggestions and interest in collaborating. Bob is right about encouraging multiple implementations, particularly as the community effort expands. The FRED technical group is not yet focused on country engagement or ensuing
implementations, though we certainly want to responsive to country use cases and any country engagement. Just to clarify, InSTEDD is developing a reference implementation as part of FRED but not subcontracted through NetHope. Ed from NetHope can comment when
he returns toward the end of November.
If you look back through the project documentation you will see that InSteDD’s ResourceMap is already contracted through NetHope to produce a reference implementation. DHIS2 will also produce an implementation (not paid for by NetHope).
The other point of standardising an api is to encourage multiple implementations, extending client choices and combating vendor lock in.
Once we have settled on a v1.0 of the spec, it would be great to get some implementations off the ground so that we have feedback for later versions.
What plans are already in the works? In particular, do we have any solid ideas about building a reference implementation? Have we considered building on top of existing work, for example InSTEDD’s Resource Map?
In Uganda, we have a use case of producing a registry server that can help various systems coordinate facility data. This could be a good focal point for collaboration on a reference implementation, in particular because as a standalone service it might
also be deployed as part of other, similar systems.
We’re very keen to collaborate if we can, because the whole point of producing a standard is interoperability and reducing duplicated effort.
Thanks for the suggestions and interest in collaborating. Bob is right
about encouraging multiple implementations, particularly as the community
effort expands. The FRED technical group is not yet focused on country
engagement or ensuing implementations, though we certainly want to
responsive to country use cases and any country engagement. Just to
clarify, InSTEDD is developing a reference implementation as part of FRED
but not subcontracted through NetHope. Ed from NetHope can comment when he
returns toward the end of November.
I guess that is Ed from InSTEDD
Best,
Kelly
------------------------------
*From:* facility-registry@googlegroups.com [
facility-registry@googlegroups.com] on behalf of Matt Berg [
mlberg@gmail.com]
*Sent:* Friday, November 23, 2012 9:21 AM
*To:* facility-registry@googlegroups.com
*Subject:* Re: Reference implementation
For Uganda, I think the hope is to use the DHIS2 implementation that I
think you'll be integrating with Chris.
Hi Chris
Its clear you have come late to this discussion
If you look back through the project documentation you will see that
InSteDD's ResourceMap is already contracted through NetHope to produce a
reference implementation. DHIS2 will also produce an implementation (not
paid for by NetHope).
The other point of standardising an api is to encourage multiple
implementations, extending client choices and combating vendor lock in.
Bob
Hi all,
Once we have settled on a v1.0 of the spec, it would be great to get
some implementations off the ground so that we have feedback for later
versions.
What plans are already in the works? In particular, do we have any
solid ideas about building a reference implementation? Have we considered
building on top of existing work, for example InSTEDD's Resource Map<http://instedd.org/technologies/resource-map/>
?
In Uganda, we have a use case of producing a registry server that can
help various systems coordinate facility data. This could be a good focal
point for collaboration on a reference implementation, in particular
because as a standalone service it might also be deployed as part of other,
similar systems.
We're very keen to collaborate if we can, because the whole point of
producing a standard is interoperability and reducing duplicated effort.
Cheers,
Chris
--
--
--
--
···
On 23 November 2012 19:19, Kelly Keisling (NH) <kelly.keisling@nethope.org>wrote:
On Fri, Nov 23, 2012 at 7:04 AM, Bob Jolliffe <bobjolliffe@gmail.com>wrote:
On 23 November 2012 11:46, Chris Ford <cford@thoughtworks.com> wrote:
Yes thanks much for correcting the holiday typo! Ed Jezierski is from InSTEDD. I’m from NetHope.
Best
Kelly
···
Hi Chris,
Thanks for the suggestions and interest in collaborating. Bob is right about encouraging multiple implementations, particularly as the community effort expands. The FRED technical group is not yet focused on country engagement or ensuing implementations,
though we certainly want to responsive to country use cases and any country engagement. Just to clarify, InSTEDD is developing a reference implementation as part of FRED but not subcontracted through NetHope. Ed from NetHope can comment when he returns toward
the end of November.
If you look back through the project documentation you will see that InSteDD’s ResourceMap is already contracted through NetHope to produce a reference implementation. DHIS2 will also produce an implementation (not paid for by NetHope).
The other point of standardising an api is to encourage multiple implementations, extending client choices and combating vendor lock in.
Once we have settled on a v1.0 of the spec, it would be great to get some implementations off the ground so that we have feedback for later versions.
What plans are already in the works? In particular, do we have any solid ideas about building a reference implementation? Have we considered building on top of existing work, for example InSTEDD’s Resource Map?
In Uganda, we have a use case of producing a registry server that can help various systems coordinate facility data. This could be a good focal point for collaboration on a reference implementation, in particular because as a standalone service it might
also be deployed as part of other, similar systems.
We’re very keen to collaborate if we can, because the whole point of producing a standard is interoperability and reducing duplicated effort.
