You are right. Stick to pure json spec is best as NeoJSON / Gson does.
Anything else should be application's headache, exactly as Gson advices, as
much is yours.
I was just not shaking of the XMLRPC / SOA approach out of my head. It is
getting cleared now. !.. let me work through my use case and come back if I
need to at all on this.
On Fri, Feb 13, 2015 at 7:04 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> Hi,
>
> I had a more detailed look at json-io and read the code a bit.
>
>
> First, this does not seem to be too popular in the Java world, there is no
> formal spec, I don't see or hear about much uptake. So from that
> perspective, why follow it ?
>
> Second, although at a first look their extensions seem reasonable, most
> are quite Java specific, some inefficient.
>
> The contents of @class is pure Java, it can even include their ugly
> primitive array syntax (like '[B') if I understood it well. How can that be
> universally mapped to another, different language ?
>
> Their handling of primitive/non-primitive types (the endless int/Integer,
> ... mess) makes the code quite complicated and some of that will probably
> come through. We don't have those artificial differences.
>
> Their custom handling of some special classes (Date, Timestamp, Timezone,
> Class, ..) is understandable but again Java specific and not formally
> written in a spec.
>
> There seems to be @items and @keys fields that look suspicious.
>
> Any non-Java language will have trouble being 100% compatible with that
> design. It is probably not impossible to do, but why would you want to do
> that ? You will always be a second rank citizen.
>
> The handling of references using @id and @ref requires that the writer
> makes two passes over the object graph (because it has to know up front
> which objects will be used as reference targets). That is inefficient.
>
> Like I said, STON does all of the above, but a bit better, IMHO, but I am
> biased of course. FUEL, although different by being binary, handles the
> same and more edge cases. When you want to magically serialise *any*
> object, you always hit (language) implementation details, which are not
> good for cross language portability.
>
>
> IMO, json-io was *not* written with the goal of being cross-platform
> (meaning cross-language).
>
> There is a reason why JSON is what it is, limitations and all. It is quite
> restricted, but it gives you portability.
>
>
> All that being said, you could perfectly use Neo-JSON as a building block
> to work with the json-io format, by going through a Maps/Lists
> (Dictionary/Array) intermediate representation. It is a bit less efficient,
> but I will work.
>
> Point>>#asJsonIo
> ^ { #'@class'->'java.awt.Point'. #x->x. #y->y } asDictionary
>
> Point class>>#fromJsonIo: map
> ^ self x: (map at: #x) y: (map at: #y)
>
> You will have to maintain a Point to 'java.awt.Point' mapping. And you
> will have to walk the object graph to handles references.
>
> But it will take time to get feature equality and a functioning
> implementation.
>
>
> Sven
>
> > On 12 Feb 2015, at 11:01, S Krish <krishnamachari.sudha...@gmail.com>
> wrote:
> >
> >
> >
> > https://github.com/jdereg/json-io
> >
> > I like the additional features of json-io : @ref / @id pair
> >
> > If we can have an JSONExtension which plays well with json-io, we have a
> simple way to interact with Java/Scala/Groovy JVM world for default.
> >
> > Present these as literals: String, Numbers, Date, Time, Literal Arrays ,
> booleans
> >
> > Rest all are type based marshalling/ unmarshalling
> >
> > "@type": "fully.qualified.name.toClass" for Pharo we can ignore the
> package name.. which can be the Category specifier for serialization
> purposes.
> >
> >
> >
> >
> > On Thu, Feb 12, 2015 at 3:05 PM, S Krish <
> krishnamachari.sudha...@gmail.com> wrote:
> >
> > Even for GSON:
> >
> >
> http://www.javacodegeeks.com/2012/04/json-with-gson-and-abstract-classes.html
> >
> > {
> >
> > "type": "Circle",
> > "properties": {
> >
> > though I prefer json-io: @type to make it unambigous for any case with
> instance variable named type and does not add another node to the tree..
> >
> >
> >
> > On Thu, Feb 12, 2015 at 2:58 PM, S Krish <
> krishnamachari.sudha...@gmail.com> wrote:
> >
> > I get your point .. like GSON we should not type the json string output,
> if we want it to adhere abs to spec.
> >
> > The saving grace for gson in Java is if you just give the root level
> object type, rest of it is automatic typing. We lack that capability in
> Pharo. Though there also for types specified as an interface can then
> require code assistance in deserializing.
> >
> > So either we follow a meta data route, code helper methods, that is
> needed for deserializing a JSON as spec or let it have an optional @type
> tag.. to make the whole thing automatic
> >
> > That way we can be both gson / or any other lib compatible for reading
> given format ignoring the extra tag, but helps if given to hydrate the
> object.
> >
> >
> >
> >
> > On Thu, Feb 12, 2015 at 1:13 PM, Sven Van Caekenberghe <s...@stfx.eu>
> wrote:
> > Hi,
> >
> > I will read a bit about json-io and come back to you.
> >
> > In any case, JSON is a standard that explicitly excludes typing info,
> and yes I know it has been added in several places. NeoJSON's mission is to
> stay true to the pure spec and to be efficient. Of course, it could be
> extended or subclassed if its original goals remain in place.
> >
> > BTW, STON is what I think JSON with typing info should be ;-)
> >
> > Sven
> >
> > > On 12 Feb 2015, at 06:33, S Krish <krishnamachari.sudha...@gmail.com>
> wrote:
> > >
> > >
> > >
> > > Can I extend NeoJSON to be more like json-io.
> > >
> > > * Object serialization
> > > * format synchronization
> > >
> > > To help make it bidirectional for Pharo to external world
> serialization / deserialization
> > >
> > >
> > > Seems the closest to what is appropriate for Pharo - Scala/ Groovy /
> Java
> > >
> > >
> > > Gson : no type information..
> > > Jackson: painful annotation or workarounds
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
