Hi Marc,
Excellent minutes, thanks for writing them with such care.
Best regards,
Jerome
> -----Message d'origine-----
> De : Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
> Envoyé : mercredi 25 avril 2007 17:26
> À : dev_at_jsr311.dev.java.net
> Objet : Draft minutes of 24 Apr telcon
>
> Draft minutes are attached below, please send any corrections to the
> list. I'll post these on the java.net site once the subversion
> repository is working again (grrr).
>
> Marc.
>
> EG tel-con meeting 24th April 2007 (DRAFT)
>
> Present
> -----------
>
> Jan Algermissen
> Bill de Hora
> Larry Cable
> Roy Fielding
> Marc Hadley
> Mark Hansen
> Ryan Heaton
> Dave Hensley
> Julian Reschke
> Paul Sandoz
>
> Minutes
> -----------
>
> 1. Round table of introductions and primary interests
>
> There was general consensus around the primary interests
> expressed by
> EG members on the need for a high-level API that is simpler than the
> Servlet API or the JAX-WS API for the development of RESTful Web
> services in Java. Phrases like "make the simple things really
> simple"
> and the "hard things possible" were commonly expressed or concurred
> with.
>
>
> 2. Discussion of goals
>
> 2.1 POJO-based
>
> General agreement on this goal. It is the 'programming style de jure'.
>
>
> 2.2 HTTP centric.
>
> There was general agreement on the following:
>
> - expose HTTP to the extent it makes sense but not build
> abstractions
> that get in the way.
>
> - HTTP is the 80% and should be well-integrated into the programming
> model.
>
> - the runtime should provide support for common cases (like content
> negotiation and caching support) but still provide full access to
> everything that HTTP provides (sans low-level container-specific
> aspects) as we can never be sure what developers will want to do.
>
> - names of annotations/classes/ifaces can be abstract from HTTP but
> need to provide clarity and limit conflicts with names commonly used
> in other contexts. The relationship to HTTP can be specified in the
> Java documentation.
>
> - design for existing HTTP usage (which includes existing protocols
> that extend HTTP, such as WebDAV) and not for future protocols that
> extend and/or improve on HTTP. It is easier to design for now and
> modify in the future.
>
>
> 2.3 Format independence
>
> There was general agreement that this API should not tie itself to
> XML. JSON, forms, N3, images, audio and video are other
> useful formats.
>
> It was expressed that sketch 2 of the API provides a good way to go
> in this respect.
>
>
> 2.4 Container independence
>
> General consensus that the API (and hence applications developed
> using it) should be independent of container. Portability of API
> implementations between containers is felt to be less important.
>
> A question was raised about lack of features in the servlet API, for
> example the lack of support for 100 (Continue) responses. We need to
> work with the Servlet EG to identify requirements and use-cases
> lacking in the servlet API that we require for support as a container.
>
>
> 2.5 Inclusion in Java EE 6
>
> General agreement.
>
> It was expressed that the current thinking is to provide something
> similar to that of JSF managed beans.
>
>
> 3. Discussion of non-goals
>
> 3.1 Client APIs
>
> General agreement.
>
>
> 3.2 No new HTTP stack.
>
> General agreement.
>
>
> 3.3 Data model/format classes
>
> General agreement.
>
>
> 4. Other goals/non-goals
>
> No other proposed goals/non-goals were presented by EG members.
>
>
> 5. Points of note during the meeting
>
> A question was asked how educational the API should be. The
> specification should be terse and, well, spec-like, but the Java
> documentation should be helpful and there is scope for good examples
> of using the APIs. It was noted that there are one or two EG members
> that are authors and that their experience in this area will be most
> helpful.
>
> It was observed that an API cannot be RESTful itself, rather the
> applications built using the API can be RESTful. There was general
> agreement that the API should lead in a certain direction where
> developers would 'naturally' build RESTful applications.
>
>
> 6. Attending Java one.
>
> Larry Cable, Marc Hadley, Dave Hensley and Paul Sandoz will be
> attending Java One.
>
> We should meet and have a beer or two and amongst other things
> discuss this API.
>
> A session on this JSR will be presented by Marc Hadley and
> Paul Sandoz:
>
> Session ID: TS-6411
> Session Title: JSR 311: The Java API for RESTful Web Services
> Track: The Next Generation Web
> Room: Esplanade 307-310
> Date: 08-MAY-07
> Start Time: 18:00
>
> 7. EOM.
>
>
>
>