Paul deserves all the credit, I just did a bit of final editing to
merge in my (much briefer) notes.
On Apr 25, 2007, at 11:49 AM, Jerome Louvel wrote:
>
> 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.
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s