Status of 2.0 WD?
weierophinney
trying to figure out what versions to support. Obviously, I plan to
support 1.0, as there are existing clients that use that format.
However, I'm in a state of confusion as to what other specifications
are
in play currently. Here's my understanding so far:
* 1.1: abandoned
* 1.2: heavily edited, given as RC1, and then renamed to 2.0
* 2.0: revised version of 1.2RC1
Is this correct?
(I'm surprised that 2.0 is not BC with 1.0, though I believe that
a well-written server could use the Request to determine which
specification to follow.)
Next, I saw a call to approve 1.2RC1/2.0 at the end of February, but
there's no clear indication in the archives as to what the consensus
was, if any. Could somebody clarify?
Next, I see a document for "JSON Schema Service Descriptor", but it is
unclear if this is the format to use for system.describe -- or if the
one in the 1.1 WD is still being considered. Additionally, there is no
clear description of SMD anywhere -- the example provided conflicts
with
implementations in other clients, such as Dojo. Can somebody clarify
at
all where I might find a concise description of system.describe and
its
format?
Finally, should I even consider anything other than 1.0 at this time?
My inclination is not to, but to consider some forward compatibility
issues such as sending HTTP 204 responses for notifications, making
sure
my scaffolding has the ability to support both by-position and by-name
parameters, using the 2.0 error codes, and having support for
system.describe (which will be needed to generate SMD files for
clients
such as Dojo anyways).
Any thoughts or advice would be welcome.
--
Matthew Weier O'Phinney
Software Architect
Zend - The PHP Company | http://www.zend.com/
Kris Zyp
> Next, I see a document for "JSON Schema Service Descriptor", but it is
> unclear if this is the format to use for system.describe -- or if the
> one in the 1.1 WD is still being considered. Additionally, there is no
> clear description of SMD anywhere -- the example provided conflicts
> with
> implementations in other clients, such as Dojo. Can somebody clarify
> at
> all where I might find a concise description of system.describe and
> its
> format?
google group:
http://groups.google.com/group/json-schema
JSON-RPC does not officially use JSON Schema or SMD, although SMD was built
with the intent of describing JSON-RPC services. The current SMD spec is at:
http://groups.google.com/group/json-schema/web/service-mapping-description-proposal
The latest RPC services in Dojo 1.1 are built on this SMD 2.0 spec. Any
divergences are probably my fault, since I am the primary author/dev for
both :), let me know if you find some. Older versions of Dojo used an older,
archaic draft of SMD.
Kris
Matthew Weier O'Phinney
Excellent -- thanks for this information.
Roland Koebler
> Here's my understanding so far:
>
> * 1.1: abandoned
right.
> * 1.2: heavily edited, given as RC1, and then renamed to 2.0
> * 2.0: revised version of 1.2RC1
the proposals for 1.2 and 2.0 were created at the same time, so 2.0
isn't really a revised version of 1.2.
> (I'm surprised that 2.0 is not BC with 1.0,
It can't, because it adds new functionality.
> though I believe that
> a well-written server could use the Request to determine which
> specification to follow.)
yes, it can, and this fact is also mentioned in the "2.0 WD"
> Next, I saw a call to approve 1.2RC1/2.0 at the end of February, but
> there's no clear indication in the archives as to what the consensus
> was, if any. Could somebody clarify?
The consensus is, that the current 2.0 WD is good, and no further
modifications to the WD are necessary.
I think we could approve it -- but there wasn't anyone here who pushed
the approval ;).
> Next, I see a document for "JSON Schema Service Descriptor", but it is
> unclear if this is the format to use for system.describe
yes, it was discussed to use it for system.describe.
but it has not yet been decided, how all the "system.*" should look like.
> Finally, should I even consider anything other than 1.0 at this time?
1.0 is the only "valid" specification at the moment.
but I personally think that there won't be any modifications to the 2.0WD,
and that it will be approved as it is. but I cannot guarantee this.
so, I would suggest to implement 1.0, and extend it as soon as 2.0 is
released. (I already implemented a JSON-RPC client and server for 1.0
and 2.0 in python, which is working really well.)
> My inclination is not to, but to consider some forward compatibility
> issues such as sending HTTP 204 responses for notifications,
remember that HTTP has *nothing* to do with JSON-RPC. JSON-RPC and the
used transport are completely independent.
regards,
Roland
Matthew Weier O'Phinney
On Sat, Mar 8, 2008 at 2:29 PM, Roland Koebler <r.ko...@yahoo.de> wrote:
> > Here's my understanding so far:
> >
> > * 1.1: abandoned
>
> right.
I don't know who maintains that spec, but a note on the top of it
indicating it's abandoned and/or deprecated would be useful. I spent a
number of hours studying it and preparing tasks before I discovered this
group -- and the fact that 1.1 is deprecated.
If you can indicate how I can contact the owner of that, I'll shoot them
an email suggesting this.
> > * 1.2: heavily edited, given as RC1, and then renamed to 2.0
> > * 2.0: revised version of 1.2RC1
> the proposals for 1.2 and 2.0 were created at the same time, so 2.0
> isn't really a revised version of 1.2.
So, is 1.2 a separate version? Has it or will it ever be approved as an
official version of the specification?
The Simple Mapping Description document that Kris pointed me to
yesterday references the 1.2 version, but the information on this list
leads me to believe that 1.2 may or may not ever see the light of day.
Again, some clarity would be nice here.
> > (I'm surprised that 2.0 is not BC with 1.0,
> It can't, because it adds new functionality.
>
>
> > though I believe that
> > a well-written server could use the Request to determine which
> > specification to follow.)
> yes, it can, and this fact is also mentioned in the "2.0 WD"
Yes, saw that. My plan is to detect via the request which version of the
specification is in play, and create the response accordingly.
> > Next, I saw a call to approve 1.2RC1/2.0 at the end of February, but
> > there's no clear indication in the archives as to what the consensus
> > was, if any. Could somebody clarify?
> The consensus is, that the current 2.0 WD is good, and no further
> modifications to the WD are necessary.
> I think we could approve it -- but there wasn't anyone here who pushed
> the approval ;).
:-)
I think there are some questions still to be answered for 2.0 at this
time. For instance:
> > Next, I see a document for "JSON Schema Service Descriptor", but it is
> > unclear if this is the format to use for system.describe
> yes, it was discussed to use it for system.describe.
> but it has not yet been decided, how all the "system.*" should look like.
The 2.0 specification merely states:
"The Service Descriptions are defined in a related specification."
However, no mention of *which* specification that may be is ever made.
May I suggest that you link to the Service Mappings Description
specification? This is oviously being used already by several client
implementations (e.g., Dojo), and seems like a natural extension to the
JSON-RPC spec.
Additionally, some note should be made of what system.* methods may be
implemented. I've used XML-RPC extensively, and personally feel these
methods would be very useful in JSON-RPC; add to that a system.describe
that aggregates most of that information (perhaps in the same format as
SMD), and I'd be pretty happy.
> > Finally, should I even consider anything other than 1.0 at this time?
> 1.0 is the only "valid" specification at the moment.
>
> but I personally think that there won't be any modifications to the 2.0WD,
> and that it will be approved as it is. but I cannot guarantee this.
>
> so, I would suggest to implement 1.0, and extend it as soon as 2.0 is
> released. (I already implemented a JSON-RPC client and server for 1.0
> and 2.0 in python, which is working really well.)
That is my plan right now. The question, however, the question remains:
are there any other versions I need to support? It's unclear what the
status of 1.2 is.
> > My inclination is not to, but to consider some forward compatibility
> > issues such as sending HTTP 204 responses for notifications,
> remember that HTTP has *nothing* to do with JSON-RPC. JSON-RPC and the
> used transport are completely independent.
I *am* aware of that. However, one note in the 2.0 spec is that *no*
response should be sent for notifications, and the discussions on-list
indicate that the best way to achieve that over HTTP -- *when* HTTP is
being used -- is a 204 response. That's all I was getting at.
Kris Zyp
> The Simple Mapping Description document that Kris pointed me to
> yesterday references the 1.2 version, but the information on this list
> leads me to believe that 1.2 may or may not ever see the light of day.
Thanks for pointing that out, I just fixed it. There is a patch in Dojo's
bug tracker for the name/version change.
Kris
Matthew Weier O'Phinney
Great -- thats one place needing clarification. :-)
Thanks for the quick response.
--
Matthew Weier O'Phinney
Matthew Weier O'Phinney
<mweiero...@gmail.com> wrote:
> On Wed, Apr 9, 2008 at 11:23 AM, Kris Zyp <kri...@gmail.com> wrote:
>
> > > The Simple Mapping Description document that Kris pointed me to
> > > yesterday references the 1.2 version, but the information on this list
> > > leads me to believe that 1.2 may or may not ever see the light of day.
> >
> > Thanks for pointing that out, I just fixed it. There is a patch in Dojo's
> > bug tracker for the name/version change.
>
> Great -- thats one place needing clarification. :-)
I meant to say "one *less* place". :-)
>
> Thanks for the quick response.
>
--
Matthew Weier O'Phinney
Roland Koebler
> So, is 1.2 a separate version? Has it or will it ever be approved as an
> official version of the specification?
no. simply forget the 1.2.
(there will never be a JSON-RPC 1.2.)
sorry for the confusion.
> I think there are some questions still to be answered for 2.0 at this
> time. For instance:
>
> > > Next, I see a document for "JSON Schema Service Descriptor", but it is
> > > unclear if this is the format to use for system.describe
> > yes, it was discussed to use it for system.describe.
> > but it has not yet been decided, how all the "system.*" should look like.
>
> The 2.0 specification merely states:
>
> "The Service Descriptions are defined in a related specification."
>
> However, no mention of *which* specification that may be is ever made.
yes, because there isn't such a specification yet. at the moment, it
even isn't clear, how this specification will look like.
the idea was to separate the services-descriptions from the basic spec,
so that the basic spec could be released soon -- without having to wait
for the service-description-specification.
> May I suggest that you link to the Service Mappings Description
> specification?
no. the SMD currently does not belong to JSON-RPC.
and AFAIK SMD currently is only a WD, and not finished.
> Additionally, some note should be made of what system.* methods may be
> implemented.
this will be in the "related service description spec".
but since I personally currently don't need them, I didn't write a
proposal for such a spec.
Kris is probably the only one who is working on this at the moment.
regards,
Roland