Re: Announcing Archie version 0.4

2018-02-23 Thread Bert Verhees
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

2018-02-23 Thread Thomas Beale
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

2018-02-23 Thread Pieter Bos
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

2018-02-23 Thread Bert Verhees
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

2018-02-23 Thread Pieter Bos
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

2018-02-23 Thread Bert Verhees
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

2018-02-23 Thread Pieter Bos
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

2018-02-23 Thread Bert Verhees
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

2018-02-23 Thread Thomas Beale
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: Announcing Archie version 0.4

2018-02-05 Thread Thomas Beale
yes, JS = javascript, TypeScript etc. No, nothing to do with Java of course. Just that JS/TS are the languages that seem to be popular for web app development these days, and Java for the back-end. The connection between front and back-end that people seem to prefer these days is REST APIs,

Re: Announcing Archie version 0.4

2018-02-04 Thread Erik Sundvall
Great work! A very good contribution both as code (with widely usable licence) and in practice as a specification debugging effort! //Erik Sundvall P.s. Regarding Javascript I’d recommend looking at the related Typescript superset instead for anybody wanting to do implement openEHR RM or AM on

Re: Announcing Archie version 0.4

2018-02-03 Thread Peter Gummer
Interaction with a JavaScript front-end could be done with any back-end programming language — it doesn’t have to be Java. So your point is that Archie's serialisation and deserialisation to JSON will will assist this? I believe Thomas’s Eiffel implementation already has JSON serialisation,

Re: Announcing Archie version 0.4

2018-02-03 Thread Pablo Pazos
Thanks Pieter, I'm sure we will use it when adl 2 time arrive for us, we are still on 1.4. On Feb 3, 2018 9:04 AM, "Pieter Bos" wrote: Or a Java app with rest api and a JavaScript frontend. Let the java application take care of parsing, validating, flattening, operational

Re: Announcing Archie version 0.4

2018-02-03 Thread Pieter Bos
Or a Java app with rest api and a JavaScript frontend. Let the java application take care of parsing, validating, flattening, operational template creation etc and send json to your front end. Archie has built-in json serialization and deserialization support. Pieter Op 3 feb. 2018 om 12:05

Re: Announcing Archie version 0.4

2018-02-03 Thread Seref Arikan
Hi Peter, Presumably via use of a transpiler or a bytecode to js/webassembly compiler. On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer wrote: > On 1 Feb 2018, at 05:13, Thomas Beale wrote: > > ... But the main interest is that we will be able to

Re: Announcing Archie version 0.4

2018-02-03 Thread Peter Gummer
On 1 Feb 2018, at 05:13, Thomas Beale wrote: > ... But the main interest is that we will be able to build new tools such as > a Java/JS replacement for the ADL Workbench, and of course things like a > high-quality, BMM-driven runtime archetype validating kernel for EHR

Re: Announcing Archie version 0.4

2018-02-01 Thread Pieter Bos
t; Date: Wednesday, 31 January 2018 at 19:13 To: "openehr-implement...@lists.openehr.org" <openehr-implement...@lists.openehr.org>, Openehr-Technical <openehr-technical@lists.openehr.org> Subject: Re: Announcing Archie version 0.4 This is excellent work, and has proven to be

Re: Announcing Archie version 0.4

2018-01-31 Thread Thomas Beale
This is excellent work, and has proven to be a great test for the AM specifications , helping me to find various errors. But the main interest is that we will be able to build new tools such as a Java/JS replacement for the ADL Workbench,

Re: Announcing Archie version 0.4

2018-01-31 Thread William Archibald
This is great! Thank you! On Wed, Jan 31, 2018 at 9:18 AM, Pieter Bos wrote: > Hi, > > We’re pleased to announce Archie version 0.4! For those of you unfamiliar > with Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a > basis for archetype modelling and

Re: Announcing Archie version 0.4

2018-01-31 Thread Bert Verhees
Thanks, Pieter, very useful, good work Best regards Bert On 31-01-18 16:18, Pieter Bos wrote: Hi, We’re pleased to announce Archie version 0.4! For those of you unfamiliar with Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for archetype modelling and EHR

Re: Announcing Archie version 0.4

2018-01-31 Thread Ian McNicoll
Hi Pieter, Can I also express my thanks on behalf of the openEHR community. Late in life I am becoming a bit of a java-ninja (well , in my dreams), so I will definitely give Archie a go. I can already think of a few really useful bits of tooling we could develop. Ian Dr Ian McNicoll mobile +44

Re: Announcing Archie version 0.4

2018-01-31 Thread Seref Arikan
Pieter, Allow me to express my appreciation and gratitude please: Archie is a fantastic piece of work, which has become my go-to library since I discovered it. Thanks a lot for all your hard work. Kind regards Seref On Wed, Jan 31, 2018 at 3:18 PM, Pieter Bos wrote: >

Announcing Archie version 0.4

2018-01-31 Thread Pieter Bos
Hi, We’re pleased to announce Archie version 0.4! For those of you unfamiliar with Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for archetype modelling and EHR implementations with ADL 2. Version 0.4 is a big change from version 0.3. Many features have been added