The tag “SunSPOT” gets mixed results. All documents and videos about the SunSPOTs platform on the web are being tagged with “spaughts” tag for easy search.

Cheers
Poorna

sorry I never noticed you had answered my comment
First of all, we used the robot as a proof of concept rather than as a valid use case. What we propose is more a mix between REST and webservices, where REST is usefull for simple actions, and webservices for more complex ones.
Yet if you want to have a clean concept (which you can still break when implementing ), it is cleaner to state that REST is there for object identification and CRUD manipulations, and webservices for the operations. That clearly separates the usages.

When you say that using WSDL for moving a robot is more complex than using REST, I agree with you. But still, you’re then more referring to a RESTful service rather than to a pure resource oriented REST CRUD manipulation. So it’s not “clean” enough (altough it definitly works).
To be as clean as possible, one would then create a subresource called robotxyz/nextlocation, and do a POST do assign the next location.

As for realtime problematics, we of course leave it up to realtime controllers to handle these issues. But nothing prevents on the command side to have a mapper allowing to use “RESTlike” commands that are converted into realtime controls. This gives a unity of REST flavor for at least the command side.

I’m open to further discussions of course ,

Regards,

Cedric

But my point wasn’t so much about the real-time matter I was more interested in what does moving the robot from point A to B is different from getting its position. Why do you think REST is not suitable for the first case but is for the latter. Does this particular difference justifies the use of a different system? If yes then why. That was more my point….

There are many optimized protocols for controlling machines. so I wouldn’t use REST for such tasks (although tcp/ip might be just fine for that…). I think REST would make sense for interacting with the robot, which wouldn’t suffer from a few seconds of delay (such as “hey robot, play this song by my favorite band”).

Yeah quite like quadraspace in some points they lack respecting all the REST blueprints but their approach is definitely good and similar to the approach we are taking.

I also quite enjoyed reading your blog entry. The idea of a Web Oriented programming is rather interesting. However, I’m not sure the example you’re taking in the case of the robot is the best. What would justify to use a WSDL to move the robot? Where do you see an advantage in doing that rather than a POST to the robot position resource? Don’t you think having two systems an a very thin line separating them is going to be rather confusing?

Now, I’m not saying WS-* are evil (unlike some of my colleagues I won’t cite ) but I would rather see them used for more complex integration scenarios than the ones involving real-world, limited devices.
I would point you to these papers on that matter (the first one is from Pautasso and Wilde, two very active and smart REST guys ):
http://www.jopera.org/docs/publications/2009/coupling
http://www.jopera.org/docs/publications/2008/restws

Hope to be able to meet you within SAP one of these days and don’t forget to reference your posts on your blog here!

Interesting concept (and I’m not saying this because I’m at SAP Research ). Marek pointed me to your site, let’s hope your approach will prove successfull. You may want to have a look at http://www.quadraspace.org/ which works on similar concepts of RESTifying access to sensors.
Of course, you may also have a look at our concept of Web Object Orientation and Internet of Objects which we shortly describe on SDN: https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/13491 and https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/14012

Regards,

Cedric