Re: New sketch of updated APIs

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 20 Apr 2007 16:36:26 +0200

Dhanji R. Prasanna wrote:
> On 4/20/07, *Paul Sandoz* <
> <>> wrote:
> Dhanji R. Prasanna wrote:
> >
> > Is there some value to us putting some sort of numbering or naming
> > scheme around each of these proposals, so we can formalize
> referring to
> > them? Perhaps at the head of the thread, like Marc does with code
> > snippets? I think we're going to run into a lot of formers and
> latters
> > otherwise ;)
> I really was referring to latter/former in reference to what you were
> saying :-)
> People who live in glass houses...I really ought to pick better
> identifiers =)

Tis really my fault! sorry!

> Just to clarify, if we used the builder approach as the high-level
> (only) case I assume it would mean moving it out of the core into the
> root package as the standard case?

Not sure it needs to be moved. The 'core' package in 'sketch 2' has sort
of evolved to be mostly anything other than annotations and spi classes.

> but i agree having some formal identifiers would be useful
> when discussing.
> See the JavaDoc of MultivaluedMap [1]. It does not break the contract of
> Map:
> public interface MultivaluedMap<K,V>
> extends java.util.Map<K,java.util.List<V>>
> Ahh I missed that the first time around (got caught up in commons
> MultiMap). This certainly puts a different spin on it. Consider my
> objection officially withdrawn. =)


> I was referring to the use of Map not to the fact there can be multiple
> values. I was wondering in this case whether List may be appropriate.
> Do you mean a list of returned metadata (i.e. headers)? Are you thinking
> of something like List<HeaderValue>?

Yes, or something generic like:

   List<Pair<String, T>>

Namely this links back to the RESTlet approach. It would be useful to
compare the pros/cons as this is quite a fundamental abstraction.


| ? + ? = To question
    Paul Sandoz