Skip to main content

[json-processing-spec users] Re: Introduction and some initial user thoughts.

  • From: Tatu Saloranta < >
  • To:
  • Subject: [json-processing-spec users] Re: Introduction and some initial user thoughts.
  • Date: Thu, 29 Mar 2012 12:13:02 -0700

Good discussion. Minor follow-up

On Thu, Mar 29, 2012 at 12:03 PM, David Illsley 
< >
 wrote:
>
> On 25 Mar 2012, at 22:54, Tatu Saloranta wrote:
>
>> On Sun, Mar 25, 2012 at 2:32 PM, David Illsley 
>> < >
>>  wrote:
>>>
>>> On 25 Mar 2012, at 20:30, Jitendra Kotamraju wrote:
>>>
>>>> I have some more internal feedback which came in late. I put that before 
>>>> bringing to the EG. Then we can discuss further.
>>>>
>>>> thanks,
>>>> Jitu
>>>> Tatu Saloranta wrote:
>>>>> On Sat, Mar 24, 2012 at 12:13 PM, David Illsley 
>>>>> < >
>>>>>  wrote:
>> ...
>>>>> One question here is whether chaining is purely for convenience,
>>>>> returning writer itself; or create a new write context. I assume this
>>>>> would be just former, which is more light-weight (although latter has
>>>>> its benefits too, since they can be more safely passed).
>>>
>>> In this case I went for a new object for each new JSON object/array. Yes, 
>>> there's an overhead, but for simple, small documents, developer 
>>> productivity/clarity outweights that (IMO). Being able to use
>>> content assist to see only valid completions is something I particularly 
>>> like with this approach.
>>> I'm not suggesting the main low-level parser API should be like this, but 
>>> a low-level API which everyone wraps isn't a huge improvement from the 
>>> status quo.
>>
>> Right, and I used such an approach with StaxMate 
>> (http://staxmate.codehaus.org).
>> I do like it. StaxMate does about this on basic Stax APIL both for
>> parsing and generation.
>>
>> One follow-up question, then, is how many APIs should we provide;
>> incremental (highest performance), tree model, builder-based?
>>
>
> I think a very efficient streaming API is clearly important as the basis 
> for things like a future json-b. A tree/navigable object model is important 
> to provide a flexible, idiomatic API for java developers. For performance 
> and reuse reasons, these APIs are likely to make simple things harder than 
> they need be. I'm keen to see built-in adjunct APIs/helper classes to make 
> use of jsonp attractive to developers.
>
>> Also: this also goes to question on how is the target group: my
>> experience with Stax API, for example, suggests that in many cases
>> it's not end developers that are the majority of users.
>> This may or may not be the case here. But framework developers have
>> quite different needs than app developers.
>
> Absolutely agreed. In most cases, I expect the streaming API to be used by 
> framework developers, and the tree API more used by app developers. I look 
> at the API I proposed to be more of a 'literal builder' API than a 
> streaming API, and I think it's app-centric.

Yes, it seems useful, more a question of scoping (what to keep in,
what out). Not all needs to be included by JSR/JCP etc. I am not
against it, as I think such APIs are very useful, for limited cost.

One more thought: it may well be possible to have such builder be
implemented by JSR code, and just rely on an implementation of
lower-level generator.
Same may be true for tree model as well; although should make it
possible to customize, if implementation is provided (partly to allow
providers to possibly optimize, partly for framework providers to
customize). Like using a factory for constructing nodes.

>
>>
>>>
>>>>>
>>>>>
>>>>>> DirectWriter.objectWriter(writer)
>>>>>>              .string("firstName", "John")
>>>>>>
>>>>>
>>>>> I assume 'string()' here means "write an Object property with name
>>>>> 'firstName', and value "John"?
>>>>> This only works in Object context (i.e. when there is an open object);
>>>>> for array contexts we need separate set of method. Here it'd be
>>>>> possibly to just take one argument.
>>>
>>> Yeah. I'm using different interfaces for writing an object and writing an 
>>> array...  see 
>>> https://github.com/davidillsley/scratch/blob/master/jsonp-wrap/src/org/i5y/json/wrap/DirectWriter.java
>>
>> Ok yes, makes sense then.
>>
>>>
>>>>>
>>>>> But more generally: should it be possible to separately write field
>>>>> name, value (in which case value write method can be shared for all
>>>>> contexts), or always require field name.
>>>>> Requiring field name can reduce cases of possible errors; but it makes
>>>>> some delegation cases more difficult, or requires caller to always
>>>>> pass field name (specifically, with object serialization value
>>>>> serializers are separate, but someone has to write field name too).
>>>>>
>>>>>
...
>> So I guess this is sort of "path methods" versus "path expressions".
>> I think both are useful, and I would love to have usable real
>> expression system. I just don't know of one that exists in usable
>> form.
>
> Does it need to be more complex than /propertyName/propertyName2/0 to go 
> via 2 objects and then get the first element of an array? Predicates and 
> the like would be cool, but necessary?

Probably not. But there are questions of quoting/escaping, so perhaps
one should be able to alternatively use something like:

/propertyName["slashed/name"]/

or

/propertyName/slashed\/name/

Also, numbers may be ambiguous (because they may refer to property
name in addition to array index), although not necessarily (since we
know the type during traversal).

I am bit ambivalent just because:

(a) Scope expansion can slow down things, but
(b) If we do not define a simple path expression now and wait others,
one may never (*) materialize

(*) never meaning, not until we just don't care any more, i.e. when
work with this spec & follow-up is done

So it's choice between pushing something through to make it happen vs
minimizing risks.

Come to think of this now I guess I am actually in favor of a _simple_
path expression language. :-)

>>>>>> instanceof checks and casting also seem to be common with the current 
>>>>>> API if you're walking an arbitrary tree and inspecting the contents. I 
>>>>>> know this is less common with JSON than with XML, but I do think it's 
>>>>>> worth making easier.
>>>>>>
>>>>>
>>>>> Right, I would want to minimize (if not possible to eliminate) such 
>>>>> checks.
>>>>>
>>>>> With Jackson, division of methods was such that all read methods are
>>>>> exposed at root JsonNode level, but modifications of structured types
>>>>> (adding properties to Objects, elements to Arrays) are exposed only at
>>>>> specific sub-type.
>>>>> (javadocs can be seen at
>>>>> [http://jackson.codehaus.org/1.9.4/javadoc/index.html], see JsonNode
>>>>> and subtypes).
>>>>>
>>>>> Many JSON packages implement their own view of Tree Model, so this is
>>>>> rather well experimented area.
>>>>>
>>>>>
>>>>>> What do you think of adding a JsonValueTypeEnum getType() to JsonValue?
>>>>>>
>>>>>
>>>>> This could work, but it is also possible to have distinct
>>>>> 'isNumber()', 'isArray()' etc methods, all implemented by all
>>>>> subtypes.
>>>>> But I think such enumeration definitely makes sense for incremental 
>>>>> parser.
>>>>>
>>>
>>> I'm personally a fan of smaller APIs, and so an enum based approach 
>>> appeals to me.
>>
>> I guess it goes to matter of taste (procedural vs OO, minimal
>> numbers), I don't have strong preference actually.
>> One possibility is to use Enums only for lowest level API; and more
>> convenient (IMO) isXxx() methods for tree model.
>
> FWIW, I'm also keen on enums because they work nicely in switch statements.

Yes.

-+ Tatu +-


[json-processing-spec users] Introduction and some initial user thoughts.

David Illsley 03/24/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

Tatu Saloranta 03/25/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

Jitendra Kotamraju 03/25/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

David Illsley 03/25/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

Tatu Saloranta 03/25/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

David Illsley 03/29/2012

[json-processing-spec users] Re: Introduction and some initial user thoughts.

Tatu Saloranta 03/29/2012
 
 
Close
loading
Please Confirm
Close