Re: Announcing Archie version 0.4

On 23-02-18 17:17, Thomas Beale wrote: On 23/02/2018 15:36, Pieter Bos wrote: For microservices with enough traffic, or for devices with limited processing power or limited bandwidth, a binary encoding makes sense. However, GRPC would not be my first choice for OpenEHR - you would have to

Re: Announcing Archie version 0.4

On 23/02/2018 15:36, Pieter Bos wrote: For microservices with enough traffic, or for devices with limited processing power or limited bandwidth, a binary encoding makes sense. However, GRPC would not be my first choice for OpenEHR - you would have to find a way to map all the inheritance in

Re: Announcing Archie version 0.4

From the tutorial you mention: 'Don't go looking for facilities similar to class inheritance, though – protocol buffers don't do that.' On 23/02/2018, 16:57, "openEHR-technical on behalf of Bert Verhees" wrote:

Re: Announcing Archie version 0.4

On 23-02-18 16:36, Pieter Bos wrote: you would have to find a way to map all the inheritance in the OpenEHR model to protocol buffers. For Java I found this web-page which explains how to do it. It is about a class with one nested class

Re: Announcing Archie version 0.4

Those are all valid points, but for many applications, I would say are not actual problems. If we're discussing the context of archetype editing tools, I would say REST with JSON is fine. HTTP traffic is usually compressed and browsers have heavily optimized their JSON parsing, making it much

Re: Announcing Archie version 0.4

On 23-02-18 14:37, Pieter Bos wrote: A small amount of JavaScript working with Json from a backend works very well for us. You don’t always need explicit class definitions. it does require a different programming style than a more object oriented language. Thomas has a point, JSON/REST is

Re: Announcing Archie version 0.4

A small amount of JavaScript working with Json from a backend works very well for us. You don’t always need explicit class definitions. it does require a different programming style than a more object oriented language. Regards, Pieter Bos Op 23 feb. 2018 om 14:21 heeft Bert Verhees

Re: Announcing Archie version 0.4

The problem with Ice is that it is not open source licensed when used in a non GPLv2 product. Another problem is that they do not publish the price of a commercial license. That are restrictions that cause many programmers not to use it. https://zeroc.com/licensing On 23-02-18 13:59, Thomas

Re: Announcing Archie version 0.4

Belated thought on this topic: a much better way to connect a JavaScript front end with a Java back end, or any similar combination, would be with a binary RPC protocol like ICE , that comes with tools to make it all work. - thomas On 05/02/2018 22:04, Thomas

Re: Creating a terminology

Hi Matthew, Great to hear from you. https://wiki.nci.nih.gov/display/lexevs/lexevs worked for me back in 2009 or so, it is apparently still alive. maybe worth taking a look at. All the best Seref On Fri, Feb 23, 2018 at 11:18 AM, Darlison, Matthew wrote: > Dear Charlie,

RE: Creating a terminology

Dear Charlie, That’s interesting, and not something I’d come across – many thanks! Is anyone aware of an open, freely available terminology service suite that could be used to experiment with what should be in a terminology in order to make it useful for various purposes..? Yours, Matthew

Re: openEHR REST APIs: any plans for Contribution semantics?

Apologies: I somehow managed to miss the Contribution resource at the bottom of EHR API documentation. On Fri, Feb 23, 2018 at 9:15 AM, Seref Arikan < serefari...@kurumsalteknoloji.com> wrote: > Greetings, > > I cannot see any resources that represent Contributions in the current > REST API

openEHR REST APIs: any plans for Contribution semantics?

Greetings, I cannot see any resources that represent Contributions in the current REST API specs. Is this on the roadmap for REST API specifications? All the best Seref ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org