Reference implementation

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?

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

Hi Chris

Its clear you have come late to this discussion :slight_smile:

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

On 23 November 2012 11:46, Chris Ford cford@thoughtworks.com wrote:

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?

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

For Uganda, I think the hope is to use the DHIS2 implementation that I think you’ll be integrating with Chris.

···

On Fri, Nov 23, 2012 at 7:04 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Chris

Its clear you have come late to this discussion :slight_smile:

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

On 23 November 2012 11:46, Chris Ford cford@thoughtworks.com wrote:

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?

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

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.

Best,

Kelly

···

On Fri, Nov 23, 2012 at 7:04 AM, Bob Jolliffe
bobjolliffe@gmail.com wrote:

Hi Chris

Its clear you have come late to this discussion :slight_smile:

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

On 23 November 2012 11:46, Chris Ford cford@thoughtworks.com wrote:

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?

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

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.

I guess that is Ed from InSTEDD :slight_smile:

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 :slight_smile:

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.

I guess that is Ed from InSTEDD :slight_smile:

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.

On Fri, Nov 23, 2012 at 7:04 AM, Bob Jolliffe
bobjolliffe@gmail.com wrote:

Hi Chris

Its clear you have come late to this discussion :slight_smile:

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

On 23 November 2012 11:46, Chris Ford cford@thoughtworks.com wrote:

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?

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