On Jan 23, 2013, at 11:14 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> I may've misunderstood what JSON-P stands for,
>
> still seems to be too late; and promoting specific JSON-P types at the spec level definitely does not look right to me
OK, yes I understand, an overloaded term ;)
-- Santiago
>
> Sergey
> On 23/01/13 15:57, Sergey Beryozkin wrote:
>> On 23/01/13 15:48, Santiago Pericas-Geertsen wrote:
>>> Hello Experts,
>>>
>>> We had an outstanding AI to look at the new JSON-P [1] API for any
>>> potential integration points. After some discussions with Jitu (the
>>> JSON-P lead), we'd like to propose adding support for the following
>>> types:
>>>
>>> (1) JsonStructure, JsonObject and JsonArray as entity parameters and
>>> return types for JAX-RS resource methods. Note that a JsonStructure is
>>> either a JsonObject or a JsonArray (a partition). If an entity param is
>>> JsonObject and an array is received (or vice-versa) an exception will be
>>> thrown.
>>>
>>> (2) We will _not_ provide any native support for JsonParser,
>>> JsonGenerator, JsonReader or JsonWriter. All these are usable with
>>> either an InputStream entity parameter or a StreamingOutput return type.
>>>
>>> Unless there are any strong objections, I will go ahead an update the
>>> spec to add support for the types in (1).
>> That is a pretty strong commitment to an approach considered to be less
>> effective than CORS, so unless there are really strong reasons for
>> adding this and given that we are really down to doing the cosmetic
>> changes + client security configuration, I'm -1 on it.
>>
>> Thanks, Sergey
>>>
>>> -- Santiago
>>>
>>> [1] http://jcp.org/en/jsr/detail?id=353
>>
>>