[Ocs] JSON spec

[Frank Karlitschek]

I think all the mentioned suggestions are good.

But please keep in mind that designing a specification like ocs is easy. The hard part is writing and porting all the servers and clients to the new spec. A new 2.0 spec without working implementations is worthless. The more we move away from the current one the more difficult it gets.
Some standardization organization only consider a spec final if at least two reference implementations exists. I think thats a good idea and we should do the same.

So the question from my point of view is who is willing to write the server and client implementations and port the existing stuff like KDE GHNS/attica for example. :-) 


Cheers
Frank




On 10.02.2012, at 15:12, Mohd Izhar Firdaus Ismail wrote:

> On Fri, Feb 10, 2012 at 8:19 PM, Laszlo Papp <lpapp at kde.org> wrote:
>> 
>>> programming wise, to me at least, its easier and faster to deal with
>>> json than xml as its very close to native types especially in python
>>> (dictionary), ruby (hash), php (key-value array), javascript ..
>> 
>> Valid point for some people, I agree. That makes me think that we
>> might need to deal with the tagattributes as well in order to not lose
>> any data, if one customer, like you, would just like to focus on the
>> json bits.
>> 
>>> though if ocs is choosing non-interchangeable format, there should be
>>> a full specification on the json format so that all data is
>>> represented. or a specification on how to transform the xml to a ocs
>>> json ..
>> 
>> It is not a problem to write a converting tool if we go with some
>> custom logic not existing out there yet. It is not the main focus for
>> now.
>> 
> 
> agree ..
> 
>>> what i noticed disappeared in the php json is -> 'details' attribute
>>> in <person details="full"> is lost. also. I'm not sure how the loss of
>>> that info will affect the clients, but loss of <meta> and <ocs> should
>>> be fine i think  ...
>> 
>> They are indeed gone. I am not sure about the reasons; maybe the
>> details tag attribute is not documented or decided yet how to work in
>> all aspects, or just obsolete ? Anyway, it does not matter as far as
>> we need to consider attributes like for the images, as you said.
>> 
>> What about just add the attributes as key/value pairs ?
>> 
>> For instance if you have:
>> <icon width="100"></icon> just treat it as it was
>> <icon><width>100</width></icon>.
> 
> how about <icon width="100" height="100">http://site/icon.jpg</icon> :) ?
> 
> anyway, I suggest to just define in the spec that icon json should
> follow this format
> {'width':100, 'height': 100, 'href': 'http://site.icon.jpg'} instead
> describing how to flatten the xml.
> 
>> 
>> Most of the time there is no need to make distinction whether the data
>> comes from attribute or element value when serializing into json. I
>> mean if you had:
>> <foo bar="x"><bar>y</bar></foo> you could not flatten them in same way
>> in json since you would have two "bar" keys under foo. If there are no
>> collisions like that, it is alright. In that corner case, you could
>> use something like this:
>> {"foo": {"attribs": {"bar": "x"}}, "children": {"bar": "y"}}, but it
>> is super verbose and uncomfortable to use. :) In such corner cases, if
>> at all, we can do something different, whereas i ca not think of a
>> single situation where i have ever had an element with identical
>> attribute name as a direct child element tag name.
> 
> yep, though I think its easier to just avoid having such cases
> altogether in future specs. I didnt notice any clash in current spec.
> 
>> 
>> Speaking of the reference implementation: would that option be
>> possible to put it under VCS ?
>> http://www.socialdesktop.org/library/lib_ocs.txt
>> 
>> Best Regards,
>> Laszlo Papp
> 
> -- 
> Mohd Izhar Firdaus Bin Ismail / KageSenshi
> Inigo Consulting (FOSS/Plone Development, Training & Services)
> http://www.inigo-tech.com
> Fedora Malaysia Contributor & Ambassador
> http://blog.kagesenshi.org
> 92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331
> _______________________________________________
> Ocs mailing list
> Ocs at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/ocs

Frank Karlitschek
karlitschek at kde.org