Re: PIT VC today - meeting minutes

30 Jan 2014
Groups audience: 

--- PIT VC Jan 30, 2014 notes ---
Attending: Tobias, Tim, Larry, Tom, Ulrich, Mark P.
1) Higher-level concerns / architecture:
- the discussion in the Google doc (at least as it was beginning of this
year) did not really reflect the ideas in the architecture diagrams.
This has somewhat changed now with more focus on concrete API methods
and implementation. The small detail discussions and things in it about
concerns of higher layers are there to keep the more elaborate upper
layers supported, but this should not feature creep into the API.
- it was also agreed that looking again a bit back towards the use cases
and the architecture is a good idea and will help us to see whether API
methods are missing and whether it will work together as desired. At
least Tim and Tobias are going to look at the use case docs again and
coordinate this through the Google doc so we don't do redundant work.
2) Data Type Registries WG development and synchronizing:
- we discussed the role of the type registries, also in view of the
architecture diagrams and clarified some things. The registries are
essentially agnostic to what you register with them, so we can register
both profiles and types and perhaps other things like property types. It
seems that there will rather be a lot of registered entities than just a
few.
- We will have to look at the information required to register a type
and see whether and how we are able to provide it without overloading
our own API methods.
3) Google doc status:
- edits are continuing, now with more focus on the later parts (API
methods and implementation). The doc needs some clean-up over time;
Tobias will take care of this.
- we did not have immediate suggestions for missing methods. The use
case analysis could reveal some gaps.
- we should do a Java API and a RESTful API, perhaps a Python API (in
this order of priority).
- the use case analysis could also point out requirements for the
implementations
4) Misc.
- EUDAT connection: There was a recent call from EUDAT looking for
further partners. It was suggested that the WG (or better, the PID IG,
as the WG will be terminated) could be a candidate there. Questions are
what sort of status EUDAT expects from such an entity and what work is
involved. Ulrich can ask at an EUDAT meeting on Monday. We can also put
this on the agenda for the Munich meeting (24/25. Feb).
- The PIT WG roadmap: Current roadmap looks like that we should come to
a stable document around P3 so we can do the implementation over summer.
The implementation does not look like too much effort; CNRI may put this
even in the proxy server.
- However, we also need some instances populated to demonstrate the
functionality. DKRZ could provide some content, though that will be
biased towards Earth Science model data and the local use cases. An idea
is to use the EUDAT connection to get some input from EUDAT user
communities. This is however a process that must be initiated soon so it
is ready before P4.
-------- Original Message --------
Subject: PIT VC today
From: Tobias Weigel <***@***.***>
To: ***@***.***-groups.org
Date: 30 Jan 2014, 13:11
--
Tobias Weigel
Department of Data Management
Deutsches Klimarechenzentrum GmbH (German Climate Computing Center)
Bundesstr. 45a
20146 Hamburg
Germany
Tel.: +49 40 460094 104
E-Mail: ***@***.***
Website: www.dkrz.de
Managing Director: Prof. Dr. Thomas Ludwig
Sitz der Gesellschaft: Hamburg
Amtsgericht Hamburg HRB 39784

  • Thomas Zastrow's picture

    Author: Thomas Zastrow

    Date: 30 Jan, 2014

    Dear all,
    Please apologize that I had to leave the meeting early.
    Tobias, thanks for the minutes, just my two cents:
    "- we should do a Java API and a RESTful API, perhaps a Python API (in
    this order of priority). "
    -> I would consider to use the Java API as the basis also for the REST
    API, beeing implemented as Java EE application.
    "The doc needs some clean-up over time; Tobias will take care of this. "
    -> Tobias, again thanks for this, maybe we would need another
    communication channel than misuing the Google Doc as chat application :-)
    Best,
    Tom

  • Tobias Weigel's picture

    Author: Tobias Weigel

    Date: 30 Jan, 2014

    -------- Original Message --------
    *Subject: *Re: [rda-pid-wg] Re: PIT VC today - meeting minutes
    *From: *ThomasZastrow
    <***@***.***>
    *To: ****@***.***-groups.org
    -------- Original Message --------
    *Subject: *Re: [rda-pid-wg] Re: PIT VC today - meeting minutes
    *From: *ThomasZastrow
    <***@***.***>
    *To: ****@***.***-groups.org
    *Date: *30 Jan 2014, 17:22
    > Dear all,
    >
    > Please apologize that I had to leave the meeting early.
    I tried to motivate your chair to speak to us, but it wouldn't comply.
    -------- Original Message --------
    *Subject: *Re: [rda-pid-wg] Re: PIT VC today - meeting minutes
    *From: *ThomasZastrow
    <***@***.***>
    *To: ****@***.***-groups.org
    *Date: *30 Jan 2014, 17:22
    > Dear all,
    >
    > Please apologize that I had to leave the meeting early.
    I tried to motivate your chair to speak to us, but it wouldn't comply.
    >
    > Tobias, thanks for the minutes, just my two cents:
    >
    > "- we should do a Java API and a RESTful API, perhaps a Python API (in
    > this order of priority). "
    >
    > -> I would consider to use the Java API as the basis also for the REST
    > API, beeing implemented as Java EE application.
    Interesting idea. Fancy, but also heavyweight. I've actually had some
    fencing with JAX-RS a while ago and though there is a learning curve to
    master, you also get all the benefits of the Java toolchain.
    -------- Original Message --------
    *Subject: *Re: [rda-pid-wg] Re: PIT VC today - meeting minutes
    *From: *ThomasZastrow
    <***@***.***>
    *To: ****@***.***-groups.org
    *Date: *30 Jan 2014, 17:22
    > Dear all,
    >
    > Please apologize that I had to leave the meeting early.
    I tried to motivate your chair to speak to us, but it wouldn't comply.
    >
    > Tobias, thanks for the minutes, just my two cents:
    >
    > "- we should do a Java API and a RESTful API, perhaps a Python API (in
    > this order of priority). "
    >
    > -> I would consider to use the Java API as the basis also for the REST
    > API, beeing implemented as Java EE application.
    Interesting idea. Fancy, but also heavyweight. I've actually had some
    fencing with JAX-RS a while ago and though there is a learning curve to
    master, you also get all the benefits of the Java toolchain.
    >
    > "The doc needs some clean-up over time; Tobias will take care of this. "
    >
    > -> Tobias, again thanks for this, maybe we would need another
    > communication channel than misuing the Google Doc as chat application :-)
    As Tim mentioned, the doc has a comment function. And there's also a
    proper chat, though sometimes I cannot find it (may be blind or using
    the wrong browser that was not written by Google). I'm also thinking
    about moving the discussion parts on things living in higher layers in a
    separate section (though not a separate document because that will be
    easily forgotten).
    Best, Tobias

  • Thomas Zastrow's picture

    Author: Thomas Zastrow

    Date: 31 Jan, 2014

    Am 30.01.2014 17:32, schrieb TobiasWeigel:
    >
    > I tried to motivate your chair to speak to us, but it wouldn't comply.
    Bad chair.
    >
    >>
    >> "- we should do a Java API and a RESTful API, perhaps a Python API
    >> (in this order of priority). "
    >>
    >> -> I would consider to use the Java API as the basis also for the
    >> REST API, beeing implemented as Java EE application.
    >
    > Interesting idea. Fancy, but also heavyweight. I've actually had some
    > fencing with JAX-RS a while ago and though there is a learning curve
    > to master, you also get all the benefits of the Java toolchain.
    >
    You are right, the learning curve for Java EE is is a little bit steep.
    But on the other hand, it is the most flexible and powerful one, also in
    terms of scalability. And it would allow us to implement the basic
    functionality as POJO Java library, adding the REST functionalitywith
    some servlets should be straightforward then.
    >
    > As Tim mentioned, the doc has a comment function. And there's also a
    > proper chat, though sometimes I cannot find it (may be blind or using
    > the wrong browser that was not written by Google). I'm also thinking
    > about moving the discussion parts on things living in higher layers in
    > a separate section (though not a separate document because that will
    > be easily forgotten).
    >
    I'll promise to be obedient.
    Best,
    Tom
    --
    Dr. Thomas Zastrow
    Rechenzentrum Garching (RZG) der Max-Planck-Gesellschaft / MPI für Plasmaphysik
    Boltzmannstrasse 2, D-85748 Garching
    Tel +49-89-3299-1457
    http://www.rzg.mpg.de
    Am 30.01.2014 17:32, schrieb TobiasWeigel:
    >
    > I tried to motivate your chair to speak to us, but it wouldn't comply.
    Bad chair.
    Am 30.01.2014 17:32, schrieb TobiasWeigel:
    >
    > I tried to motivate your chair to speak to us, but it wouldn't comply.
    Bad chair.
    >
    >>
    >> "- we should do a Java API and a RESTful API, perhaps a Python API
    >> (in this order of priority). "
    >>
    >> -> I would consider to use the Java API as the basis also for the
    >> REST API, beeing implemented as Java EE application.
    >
    > Interesting idea. Fancy, but also heavyweight. I've actually had some
    > fencing with JAX-RS a while ago and though there is a learning curve
    > to master, you also get all the benefits of the Java toolchain.
    >
    You are right, the learning curve for Java EE is is a little bit steep.
    But on the other hand, it is the most flexible and powerful one, also in
    terms of scalability. And it would allow us to implement the basic
    functionality as POJO Java library, adding the REST functionalitywith
    some servlets should be straightforward then.
    I'll promise to be obedient.
    Best,
    Tom
    --
    Dr. Thomas Zastrow
    Rechenzentrum Garching (RZG) der Max-Planck-Gesellschaft / MPI für Plasmaphysik
    Boltzmannstrasse 2, D-85748 Garching
    Tel +49-89-3299-1457
    http://www.rzg.mpg.de

submit a comment