Thread: tripzero's thoughts on the data standard.

XML for sure, since I don't think we're contemplating returning lots of data or objects. I'd like to think of the OSDash services as reasonably lightweight from a bandwidth standpoint.

Encapsulating it in the /osdash tags is what would make it the osdash data standard. Interchanges that involve <osdash></osdash>. Should it *always* return the session ID for security purposes?

Maybe a good way to define what is in it is to explain what we want it to do. For example, I'd like eventually to be able to load the elements of a skin from a skinning service. Does that mean it has to define things like <button> or <textbox> or image locations or are those more specific to the actual service and consumer of the service?

Should we have external and internal resources like URL's or file locations or are those more useful on a service by service perspective? Maybe it would be useful to 'point' to an adaptation or configuration file in the standard so that if the client is a mobile phone or headless (Sheeva) that it would use those files for consuming services?

Originally Posted by Bugbyte

XML for sure, since I don't think we're contemplating returning lots of data or objects. I'd like to think of the OSDash services as reasonably lightweight from a bandwidth standpoint.

Encapsulating it in the /osdash tags is what would make it the osdash data standard. Interchanges that involve <osdash></osdash>. Should it *always* return the session ID for security purposes?

Maybe a good way to define what is in it is to explain what we want it to do. For example, I'd like eventually to be able to load the elements of a skin from a skinning service. Does that mean it has to define things like <button> or <textbox> or image locations or are those more specific to the actual service and consumer of the service?

I think you bring up a good point. Each web service is likely going to be the "standard" that changes. For this reason, we should probably wrap each service in a tag:

Code:

<osdash>
  <login api="0.1" >
    <session>1232131231abadedf12</session>
  </login>
</osdash>

Also, each webservice will have to define, and hopefully document, its own standard like you are suggesting. For example, <button> <text> aren't generic tags likely to be seen anywhere but the skinning service, so the skinning service would document and define them.

Should we have external and internal resources like URL's or file locations or are those more useful on a service by service perspective? Maybe it would be useful to 'point' to an adaptation or configuration file in the standard so that if the client is a mobile phone or headless (Sheeva) that it would use those files for consuming services?

I'm not sure what you mean by this :S. Are you talking about some sort of local config that the client would use to know what services to use and where (url)?

Originally Posted by Bugbyte

XML for sure

Originally Posted by Bugbyte

I'd like to think of the OSDash services as reasonably lightweight from a bandwidth standpoint.

Were those two really next to each other? XML is the most bandwidth intensive transport protocol we could use....but in this case we need the standardization.

Originally Posted by Bugbyte

Encapsulating it in the /osdash tags is what would make it the osdash data standard. Interchanges that involve <osdash></osdash>. Should it *always* return the session ID for security purposes?

You lost me here...did you mean return or send? The only service that should "return" a sessionID is the login service.

Originally Posted by Bugbyte

Maybe a good way to define what is in it is to explain what we want it to do. For example, I'd like eventually to be able to load the elements of a skin from a skinning service. Does that mean it has to define things like <button> or <textbox> or image locations or are those more specific to the actual service and consumer of the service?

Should we have external and internal resources like URL's or file locations or are those more useful on a service by service perspective? Maybe it would be useful to 'point' to an adaptation or configuration file in the standard so that if the client is a mobile phone or headless (Sheeva) that it would use those files for consuming services?

what kev said

Originally Posted by kev000

I think we've all agreed that the technology of choice should should be restful. Since restful services return xml, i suppose we can say that XML is the data standard. Obviously, the web service should return relevant data for each service, what else would be useful for the client to return? For example, the login service would return a session key:

Because most of the node names and attributes will be service-specific, like "session" is for the login service, I suppose the stuff that we can standardize is the root elements and associated attributes, maybe error nodes? What else?

The error node should be standardized across all services. What you have works fine, a single node named error with the description inside. Other then that all you can really standardize is the root node, and that the next element should be the service name with its version as an attribute (although other attributes are optional on a service by service basis).

Originally Posted by kev000

I'm not sure what you mean by this :S. Are you talking about some sort of local config that the client would use to know what services to use and where (url)?

That's what I'm alluding to. The server may not always be up and running or the connection may not always be available to the server. The client should probably have some local adaptation files that allow it to function when that is the case. Like if there's no connection to the gps location service, should it just throw away the location data when that's the case and only relay it when the connection is restored? Or should it have a secondary location on local storage that it places that information in until it reestablishes contact with the server.

And vice versa. Maybe there's data that it can get from the service that it doesn't need just yet, but can cache ahead of time in case the connection is lost. If it can't get that info from the service, it can refer to a local copy of the data until the connection is reestablished.

I don't know if that's consistent with a stateless service or not. Or if I'm making up a problem that won't occur when using these services.

Also, is it possible that different types of hardware will require different types of information for a client to do the same thing? Like dbus vs. ipc or whatever (I'm way out of my element here) so that you can select how the client does a limited number of things?

Different question about what kind of data is allowed to be exchanged

In addition, I don't want to hit the server up with a lot of bandwidth consuming stuff that has nothing to do with the web services themselves. So, for example, if someone comes up with a service that uses a lot of bandwidth, like involving the transfer of files, you would want to enable a web service to *direct* that activity without involving the server itself.

Different example. Let's say you have a service that checks for traffic problems, does some kind of intelligent processing to build you a customized traffic report and converts the text of the report into an audio file that plays shortly after you start the car. How do you tell the client to download that file and what to do with it after it downloads it?

Is that something that is service specific or client specific or both? I'd think the service could send a notification to the server and the client could check for it from time to time, like on startup or poll every so often, or maybe even just receive and email of the notice, but it definitely shouldn't be allowed to roll up that file inside a set of <osdash> tags and send it to the server for later retrieval.

There may be more elegant or straightforward ways to solve this problem or it may not be a problem at all. I was thinking that the client might have some provision for how it handles the transfer of files like music or images both in where it gets them from and where it stores them.

Ah that clears things up... yea some services will require local caching but thats a service specific thing and implemented in each client (for example the linuxICE client may want to use mysql where as the rr client may want to use text files .

Regarding the whole bandwidth issue yea thats why I've been pushing so hard for a scalable system. The single server concept has been dead for at least ten years now. With multiple mirrors there really isn't an issue with bandwidth intensive services...and file transfer would happen as a raw binary transfer, its not possible to do as a higher level service.

How the client stores settings and data is really an implementation detail of the client and is slightly out of scope in this discussion. However, it is an important topic and should be discusses in another thread.