SMD

[jgautier]

Hi All,

The SMD spec looks very cool but the last update to it was back in
2008. Is this still a standard that is trying to be developed? Is
there another specification that accomplishes the same thing that is
more up to date? Also has there been any plan on of using websockets
for a transport in SMD?

Thanks,

Julian

[Clay Loveless]

Just nudging this thread. I'm interested in the answers to these
questions as well.

-Clay

[Gary Court]

I'm pretty sure this was just a proposal put forth by Kris. Nothing
has come of it, and no push was ever made to standardize it.

I think that means you are free to take it as you will and run with
it. Why not contribute or standardize it?

-Gary

[Luis Montes]

It is a little more than just a a proposal.

The dojo has a very good implementation of a client side implementation in javascript.that uses the SMD spec.

Take a look at dojox.rpc.Service  http://docs.dojocampus.org/dojox/rpc/Service

Luis

--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To post to this group, send email to json-...@googlegroups.com.
To unsubscribe from this group, send email to json-schema...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-schema?hl=en.

[Clay Loveless]

Thanks, Luis. Doubt the Dojo folks would be interested in someone hijacking the spec and attempting to get it through a standards process without their input. 

Any ideas on who to reach out to at Dojo for more details around Julian's questions? Despite support in Dojo, the spec does have a tumbleweed vibe. If Kris is no longer maintaining it, then hopping in would be a different story.

-Clay

--

Sent from my iPhone

[Luis Montes]

I can't speak for Kris or dojo, but it wouldn't hurt to ask him.  He's usually on freenode.

The spec is pretty ambitious considering its covering multiple message formats and transports. I know I'd personally like to a couple of enhancements.

Luis

[Kris Zyp]

I personally have kind of lost interest in working on SMD just because
I have been more focused on REST-oriented approaches (hyper-schema
which is different than a service description approach). However, we
are definitely still using SMD in Dojo, so it definitely sees usage.
If anyone wants to lead any improvements/edits to SMD, that is fine by
me.
Kris

On Aug 23, 10:52 am, Luis Montes <monte...@gmail.com> wrote:
> I can't speak for Kris or dojo, but it wouldn't hurt to ask him.  He's
> usually on freenode.
>
> The spec is pretty ambitious considering its covering multiple message
> formats and transports. I know I'd personally like to a couple of
> enhancements.
>
> Luis
>
>
>
> On Thu, Aug 19, 2010 at 10:27 AM, Clay Loveless <c...@killersoft.com> wrote:
> > Thanks, Luis. Doubt the Dojo folks would be interested in someone hijacking
> > the spec and attempting to get it through a standards process without their
> > input.
>
> > Any ideas on who to reach out to at Dojo for more details around Julian's
> > questions? Despite support in Dojo, the spec does have a tumbleweed vibe. If
> > Kris is no longer maintaining it, then hopping in would be a different
> > story.
>
> > -Clay
> > --
> > Sent from my iPhone
>

> > On Aug 19, 2010, at 9:25 AM, Luis Montes <monte...@gmail.com> wrote:
>
> > It is a little more than just a a proposal.
>
> > The dojo has a very good implementation of a client side implementation in
> > javascript.that uses the SMD spec.
>
> > Take a look at dojox.rpc.Service
> > <http://docs.dojocampus.org/dojox/rpc/Service>
> >http://docs.dojocampus.org/dojox/rpc/Service
>
> > Luis
>

> > On Wed, Aug 18, 2010 at 9:25 PM, Gary Court < <gary.co...@gmail.com>
> > gary.co...@gmail.com> wrote:
>
> >> I'm pretty sure this was just a proposal put forth by Kris. Nothing
> >> has come of it, and no push was ever made to standardize it.
>
> >> I think that means you are free to take it as you will and run with
> >> it. Why not contribute or standardize it?
>
> >> -Gary
>
> >> On Aug 18, 6:05 pm, Clay Loveless <c...@killersoft.com> wrote:
> >> > On Aug 5, 2:06 pm, jgautier <julian.gaut...@alumni.neumont.edu> wrote:
>
> >> > > Hi All,
>
> >> > > The SMD spec looks very cool but the last update to it was back in
> >> > > 2008.  Is this still a standard that is trying to be developed?  Is
> >> > > there another specification that accomplishes the same thing that is
> >> > > more up to date?  Also has there been any plan on of using websockets
> >> > > for a transport in SMD?
>
> >> > Just nudging this thread. I'm interested in the answers to these
> >> > questions as well.
>
> >> > -Clay
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "JSON Schema" group.
> >> To post to this group, send email to <json-...@googlegroups.com>
> >> json-...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> <json-schema%2Bunsu...@googlegroups.com>

> >> json-schema...@googlegroups.com.
> >> For more options, visit this group at
> >> <http://groups.google.com/group/json-schema?hl=en>
> >>http://groups.google.com/group/json-schema?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "JSON Schema" group.
> > To post to this group, send email to json-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > json-schema...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/json-schema?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "JSON Schema" group.
> > To post to this group, send email to json-...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > json-schema...@googlegroups.com<json-schema%2Bunsubscribe@googlegr oups.com>
> > .

[Clay Loveless]

Kris,

Thanks for jumping in on this thread. Can you summarize, or point to a summary, of hyper-schema and how it differs conceptually from SMD?

At Mashery, we've been trying to settle in an approach for driving API browser-consoles (to test drive API calls), and felt SMD was a better approach than WADL or WSDL 2.0. So, I'd really appreciate more info on hyper-schema and why it's more suitable to you these days.

Thanks!

-Clay
--
Sent from my iPhone

[Kris Zyp]

On 8/24/2010 9:05 AM, Clay Loveless wrote:
> Kris,
>
> Thanks for jumping in on this thread. Can you summarize, or point to a summary, of hyper-schema and how it differs conceptually from SMD?

Mainly SMD is designed based on RPC architecture (focusing on mapping
requests to method calls), and hyper-schema is designed based on REST
architecture (uniform interface, HATEOS, etc.).

> At Mashery, we've been trying to settle in an approach for driving API browser-consoles (to test drive API calls), and felt SMD was a better approach than WADL or WSDL 2.0. So, I'd really appreciate more info on hyper-schema and why it's more suitable to you these days.

There is certainly plenty of descriptions and discussions on REST vs
RPC/SOAP style architectures to be found on the web, I am not going to
try to recreate that here. And it can certainly get into philosophical
differences. I just have tended towards the REST camp.

--
Thanks,
Kris

[Clay Loveless]

On Aug 24, 2010, at 8:28 AM, Kris Zyp wrote:

> Mainly SMD is designed based on RPC architecture (focusing on mapping
> requests to method calls), and hyper-schema is designed based on REST
> architecture (uniform interface, HATEOS, etc.).
>> At Mashery, we've been trying to settle in an approach for driving API browser-consoles (to test drive API calls), and felt SMD was a better approach than WADL or WSDL 2.0. So, I'd really appreciate more info on hyper-schema and why it's more suitable to you these days.
>
> There is certainly plenty of descriptions and discussions on REST vs
> RPC/SOAP style architectures to be found on the web, I am not going to
> try to recreate that here. And it can certainly get into philosophical
> differences. I just have tended towards the REST camp.

I get all of that, and am similarly not interested in a philosophical debate or even RPC vs REST. I was just under the impression that SMD was intended to be suitable for describing both RPC _and_ REST, though there are scant (if any) comprehensive examples of SMD describing REST well, at least that I've seen.

At what point did you decide that SMD, while originally intended to adequate for describing REST, wasn't up to it?

-Clay

--
Clay Loveless
Founder
w: http://killersoft.com
t: @claylo

[Kris Zyp]

You certainly can describe, or more accurately, map a REST web service
to a method using SMD, SMD is certainly appropriate for that, but the
whole notion of mapping services to methods is beyond the REST
architecture that is focused on the use of uniform interface rather than
specific methods. In the colloquial, REST services usually denote
services that provide data through GETable URLs, but often does not
imply full usage of all the elements of the REST architecture. The REST
architecture describes a completely different approach than mapping
services to methods. But if the goal is mapping "REST" or GET/URL based
web-based services to methods, that is still handled well by SMD.

--
Thanks,
Kris

[jgautier]

Would there be any issue adding Websockets as a transport in SMD?

[Lo Sauer]

I too am wondering where the support for SMD has gone recently. Initially google, yahoo and others jumped on the bandwagon.

Currently I am in the process of implementing a client-server architecture based on SMD and PHP as a light backend interface. However a python-django interface should be simple to implement as well. Strong websocket support is planned.
Update and whitepaper soon in github.  https://github.com/lsauer/  (The project's name isn't decided yet)

[Luis Montes]

Bumping this really old thread because I think things have changed quite a bit since the thread was started.

I've been using JSON-RPC over websockets with client side deffereds for a while now and it has been working out extremely well.  In fact, for most webapps I'd now rather start with JSON-RPC then to bother with REST mappings for a good chunk of the app's functionality.  In particular single-page apps do not require a ton of REST mappings aside from the full page loads.  Using an rpc call over an established websocket is much faster than sending a new XMLHttpRequest.

That said, it could be even better.  

In certain cases JSON-RPC 2.0 notifications could be used instead of full requests.  Would be nice for the SMD spec to be able mark methods as such so the client side doesn't have to bother creating a Deffered object or callback handler for it.

Luis

--

You received this message because you are subscribed to the Google Groups "JSON Schema" group.

To view this discussion on the web visit https://groups.google.com/d/msg/json-schema/-/pfwMRefsn1wJ.

[Francis Galiegue]

Hello,

On Mon, Feb 4, 2013 at 3:43 PM, Luis Montes <mont...@gmail.com> wrote:
> Bumping this really old thread because I think things have changed quite a
> bit since the thread was started.
>
> I've been using JSON-RPC over websockets with client side deffereds for a
> while now and it has been working out extremely well. In fact, for most
> webapps I'd now rather start with JSON-RPC then to bother with REST mappings
> for a good chunk of the app's functionality. In particular single-page apps
> do not require a ton of REST mappings aside from the full page loads. Using
> an rpc call over an established websocket is much faster than sending a new
> XMLHttpRequest.
>
>
> That said, it could be even better.
>
> In certain cases JSON-RPC 2.0 notifications could be used instead of full
> requests. Would be nice for the SMD spec to be able mark methods as such so
> the client side doesn't have to bother creating a Deffered object or
> callback handler for it.
>

Is this what you are refering to?

http://dojotoolkit.org/reference-guide/1.8/dojox/rpc/smd.html

If yes, I guess I could write a schema for it :p

And also for JSON RPC while we are at it...

To (not) answer your question, this is the first time I've heard of SMD.

How do you see JSON Schema as being able to help here? Apart from
writing schemas for both of the aforementioned JSON formats, that is.

--
Francis Galiegue, fgal...@gmail.com
Try out your JSON Schemas: http://json-schema-validator.herokuapp.com

[Francis Galiegue]

On Mon, Feb 4, 2013 at 3:52 PM, Francis Galiegue <fgal...@gmail.com> wrote:
> Hello,
>
> On Mon, Feb 4, 2013 at 3:43 PM, Luis Montes <mont...@gmail.com> wrote:
>> Bumping this really old thread because I think things have changed quite a
>> bit since the thread was started.
>>
>> I've been using JSON-RPC over websockets with client side deffereds for a
>> while now and it has been working out extremely well. In fact, for most
>> webapps I'd now rather start with JSON-RPC then to bother with REST mappings
>> for a good chunk of the app's functionality. In particular single-page apps
>> do not require a ton of REST mappings aside from the full page loads. Using
>> an rpc call over an established websocket is much faster than sending a new
>> XMLHttpRequest.
>>
>>
>> That said, it could be even better.
>>
>> In certain cases JSON-RPC 2.0 notifications could be used instead of full
>> requests. Would be nice for the SMD spec to be able mark methods as such so
>> the client side doesn't have to bother creating a Deffered object or
>> callback handler for it.
>>
>
> Is this what you are refering to?
>
> http://dojotoolkit.org/reference-guide/1.8/dojox/rpc/smd.html
>
> If yes, I guess I could write a schema for it :p
>

And here goes:

* https://github.com/fge/json-schema-validator/blob/master/src/main/resources/smd-service.json
* https://github.com/fge/json-schema-validator/blob/master/src/main/resources/smd.json

> And also for JSON RPC while we are at it...
>

Now, looking at that...

[Luis Montes]

Yup, I'm using dojo's smd schema.

One way it is able to help, is that when I establish a socket connection to a json-rpc capable server I ask then receive an SMD object.  I use that object to construct an rpc client proxy with function names matching the SMD service names.  The execution of those functions return Deferreds.

Makes for really simple and clean client-side code.

Luis

--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.

To unsubscribe from this group and stop receiving emails from it, send an email to json-schema...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Francis Galiegue]

On Mon, Feb 4, 2013 at 5:45 PM, Luis Montes <mont...@gmail.com> wrote:
> Yup, I'm using dojo's smd schema.
>

Where is it located?

> One way it is able to help, is that when I establish a socket connection to
> a json-rpc capable server I ask then receive an SMD object. I use that
> object to construct an rpc client proxy with function names matching the SMD
> service names. The execution of those functions return Deferreds.
>
> Makes for really simple and clean client-side code.
>

Hmm, well, JSON Schema can help validate that an SMD is what it is,
but what you would like is for it to interpret SMD responses? I'm
afraid I don't really understand...

Would you mind giving an example?

[Sky Sanders]

i think luis may be suggesting a wholesale update of the smd infrastructure, including the abandoned SMD spec as well as it's partial implementation in the Dojo toolkit.

[Francis Galiegue]

On Mon, Feb 4, 2013 at 6:23 PM, Sky Sanders <sky.s...@gmail.com> wrote:
> i think luis may be suggesting a wholesale update of the smd infrastructure,
> including the abandoned SMD spec as well as it's partial implementation in
> the Dojo toolkit.
>

You mean, that JSON Schema revive SMD? That is quite ambitious.

Or did I completely misunderstand?

[Sky Sanders]

i don't know. have to ask luis.  i am just trying to give him some context for his question.

[Lo Sauer]

Luis,

>  Would be nice for the SMD spec to be able mark methods as such so the client side doesn't have to bother creating a Deffered object or callback handler for it.

I did implement this a while ago. The only question is if and how fast you need it?

(Indeed I extended the SMD - specs a bit, with backwards compatibility in mind )

regards, lo

[Luis Montes]

Sooner the better :)

One small problem i have with the current SMD spec is that since I can't distinguish what should be a notification vs a normal method call, I have to create a Deffered for both cases.  In practice this means I don't have way to clean up deferreds on notifications and I have to either leak memory, or respond from the server when i don't really need to.

[Francis Galiegue]

On Mon, Feb 4, 2013 at 10:11 PM, Luis Montes <mont...@gmail.com> wrote:
> Sooner the better :)
>
> One small problem i have with the current SMD spec is that since I can't
> distinguish what should be a notification vs a normal method call, I have to
> create a Deffered for both cases. In practice this means I don't have way
> to clean up deferreds on notifications and I have to either leak memory, or
> respond from the server when i don't really need to.
>

Maybe you need something other than a _service_ mapping description,
then? That would mean modifying the SMD spec itself.

[Luis Montes]

I think it still falls under SMD.  The ability to receive notifications without responses is something a service endpoint could have.  And it's in the JSON-RPC spec. 

I'm totally fine with the spec being updated :)

[Francis Galiegue]

On Tue, Feb 5, 2013 at 12:17 AM, Luis Montes <mont...@gmail.com> wrote:
> I think it still falls under SMD. The ability to receive notifications
> without responses is something a service endpoint could have. And it's in
> the JSON-RPC spec.
>
> I'm totally fine with the spec being updated :)
>

Have you poked the SMD guys about this?

[Francis Galiegue]

On Tue, Feb 5, 2013 at 12:17 AM, Luis Montes <mont...@gmail.com> wrote:

> I think it still falls under SMD. The ability to receive notifications
> without responses is something a service endpoint could have. And it's in
> the JSON-RPC spec.
>
> I'm totally fine with the spec being updated :)
>

The question is now, is it up to JSON Schema? Good question.

JSON Schema has hyper schema, which can interpret JSON data as
"arbitrary" (but described) content. SMD could be seen as JSON Schema
describing services. And in fact, SMD uses JSON Schema to describe its
inputs and outputs.

I am too much of a low level person here. I can describe IP, TCP and
even SCTP, but this kind of upper level consideration is beyond me. As
such, I wouldn't be the person for that. Can this be made into an IETF
draft?

[Lo Sauer]

Luis M.,

See my summary of changes to SMD here: https://docs.google.com/document/d/1XMR7ewrEKvvFi1oAMVUJcEp9xm4_uqTokbRVbWgxA2A/edit?usp=sharing

I hope it may be useful to you.

At the time at which I started out with the RPC (over a year ago), I needed a fast standalone, lightweight JSON-RPC, that does not require loading the entire DOJO-base.

Now with a stable websocket draft and finally WebRTC support the landscape of possibilities is changing.

Francis G., I poked about the status. See:

https://twitter.com/kriszyp/status/149579027471011840

[Francis Galiegue]

On Sat, Feb 9, 2013 at 12:33 PM, Lo Sauer <brainbr...@gmail.com> wrote:
[...]

>
> Francis G., I poked about the status. See:
> https://twitter.com/kriszyp/status/149579027471011840
>

Eh, I didn't even know Kris Zyp was the author of this spec too!

I'll read the changes when I get the time. Will that mean changing the
schema I wrote?