Hi,

Hijack already returns the results in either HTML or XML. Why not ecncode the results with SOAP so that it will be easy to consume on the client side. There are already many clients which can consume web-service. What you people think?

Regards
Arvind

Hijack compiles fairly cleanly already.. not sure if it really needs some soap.


(somebody had to do it)

I want to do it. I need your support. Here is the proof of concept:

1) Implement POST request in khttpd
2) Write a tiny SOAP parser
3) Add a "?WSDL" GET request to get the manifest.

What do you think?

Regards
Arvind

Here's my proof of concept:

1. Lather
2. Rinse
3. Repeat

Seriously, though, what is this going to get us?

Write a tiny SOAP parser

SOAP is a bloated variant of XML.
XML is a bloated variant of SGML.
SGML is bloated text.

"Tiny SOAP parser" therefore seems pretty oxymoronic to me.

I'm sorry to poo-poo your idea, but if SOAP gets implemented before the userland API improvements I've been begging for, I'm going to cry. Would you mind sharing what it is that you're using that requires *web services support* on your empeg? I work for a $550 billion mutual fund company and we're not even using web services yet because the specs and standards are changing every three days.

1. Lather
2. Rinse
3. Repeat
   

Always repeat.

Hijack already returns values in XML, do you think Hijack has XML parser? No, all it has is a tiny XML generator. Similarly I can write one tiny SOAP parser to just do the job.

Yes, SOAP is changing, so as the others. Don't apply the same rules for $550bn company and this small project.

Seriously, though, what is this going to get us?

[roger]We could throw away Emplode and rewrite it in XSLT!![/roger]

Peter

SOAP is a standard like HTML or XML. If Hijack supports SOAP, it is very easy to write clients for the empeg. So the advantage is, you will find more clients(GUI) to play with empeg. Right now, we have emplode, JEmplode and Web-Interface. One can integrage empeg into there applications easily.

If it's ``like HTML or XML'', then how is being able to retrieve data from it in yet another way going to help anything?

I'm not trying to crap on your idea; I really don't understand how it could provide anything we don't already have.

HTML is a standard that can be easily represented in an application that implements the standard.

XML is also a standard, but I a random application that supports 'XML' doesn't necessarily know what to do with the information in the XML file. I have a lot of problems with XML, if someone gives me a 'foo.xml' file there is no easy way to figure out whether it is the configuration file of some application, or a data file for another one, or an interface description for the third.

What makes you think that some random SOAP client would actually be any useful? My guess is that it would require implementing something that actually understands the data encapsulated in the file, in which case you could just as well use an XML or HTML parser.

Please show some concrete examples to support the case for SOAP.

For example, show the HTTP request / response sequence for a typical application, with the GET/POST commands/args and the responses from khttpd.

Just think up something fairly trivial that SOAP could do for us, and then show the data flow back/forth required for it.

Thanks.

Here is an example for GetPlayList(int uiFID);

SOAP
The following is a sample SOAP request and response. The placeholders shown need to be replaced with actual values.

POST /RioCar/Service1.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://tempuri.org/GetPlayList"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetPlayList xmlns="http://tempuri.org/">
<uiFID>int</uiFID>
</GetPlayList>
</soap:Body>
</soap:Envelope>
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetPlayListResponse xmlns="http://tempuri.org/">
<GetPlayListResult>
<structItem>
<szType>string</szType>
<uiTagFID>int</uiTagFID>
<uiFID>int</uiFID>
<uiYear>int</uiYear>
<szOptions>string</szOptions>
<szGenre>string</szGenre>
<szTitle>string</szTitle>
<szArtist>string</szArtist>
<szSource>string</szSource>
<szComment>string</szComment>
<szLength>int</szLength>
</structItem>
<structItem>
<szType>string</szType>
<uiTagFID>int</uiTagFID>
<uiFID>int</uiFID>
<uiYear>int</uiYear>
<szOptions>string</szOptions>
<szGenre>string</szGenre>
<szTitle>string</szTitle>
<szArtist>string</szArtist>
<szSource>string</szSource>
<szComment>string</szComment>
<szLength>int</szLength>
</structItem>
</GetPlayListResult>
</GetPlayListResponse>
</soap:Body>
</soap:Envelope>
HTTP POST
The following is a sample HTTP POST request and response. The placeholders shown need to be replaced with actual values.

POST /RioCar/Service1.asmx/GetPlayList HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: length

uiFID=string
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfStructItem xmlns="http://tempuri.org/">
<structItem>
<szType>string</szType>
<uiTagFID>int</uiTagFID>
<uiFID>int</uiFID>
<uiYear>int</uiYear>
<szOptions>string</szOptions>
<szGenre>string</szGenre>
<szTitle>string</szTitle>
<szArtist>string</szArtist>
<szSource>string</szSource>
<szComment>string</szComment>
<szLength>int</szLength>
</structItem>
<structItem>
<szType>string</szType>
<uiTagFID>int</uiTagFID>
<uiFID>int</uiFID>
<uiYear>int</uiYear>
<szOptions>string</szOptions>
<szGenre>string</szGenre>
<szTitle>string</szTitle>
<szArtist>string</szArtist>
<szSource>string</szSource>
<szComment>string</szComment>
<szLength>int</szLength>
</structItem>
</ArrayOfStructItem>

Why would this require POST, rather than using (existing) GET ?

Because the actual data sent in the request is transmitted in the body of the request, rather than being passed in the URL.

But, ... why?

Because that is the way HTTP requests work, GETs just request data with details given in the URI provided, POSTs also have details in the URI but also have the body of the request to take care of. The amount of data you can send in a GET is limited by the maximum URI length (practically about 2048 bytes). The data you can send in a POST is effectively unlimited.

The RFC for HTTP 1.1, kind of says this, but in a typically RFCish round about way:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3

"The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI."

and

"The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line."

See, clear as mud...

Edit:

Looking through the RFC again, there isn't anything that says a GET request can't have a body, but never the less it is normally used without a body.

Another edit:

Some more reading suggests that some people are making SOAP calls using HTTP GETs, but only when they aren't passing any arguments to the call.

Oh, good.

So, in other words, there's no particular need to bloat Hijack with a rarely used POST implementation just for this thing that I will probably never use.

Good!

I think what the original poster is trying to accomplish hasn't exactly been explained fully. I think what he's trying to do is abstract all the functionality of Emplode and JEmplode with SOAP, which sometimes is used like RPC, and isn't always just a wrapper around an XML document. If I'm guessing right, there would be functionality to upload a file, etc. along with the existing functionality of getting a playlist and song details. This would require a lot more than just POST functionality in Hijack, and IMO the extra stuff would just be bloat.

I don't see a need for any additional functionality that JEmplode or Emplode doesn't give us already. What I would like to see is a web interface that works fully in Mozilla, but SOAP will not give us that. SOAP is a good idea for Web Services, but the whole concept of SOAP and Web Services is to provide a common way of accessing data for many different parties, such as a B2B application. This makes it easy for large corporations to buy a software package and make it work with other software packages out of the box (the whole concept of data abstraction). All the software for the Empeg is custom developed anyway, so we really shouldn't need any data abstraction beyond XML.

Summary: No SOAP for you! (unless it gives us something really, really cool that can't be done any other way, which I haven't seen yet)

"No SOAP for you" I have the recipe now. I can prepare for myself. I like those Seinfield episodes. Anyway, by adding SOAP does not give anything immediately, but indirectly it opens up the door for writing applications which work seamless across firewalls, since it will be based on HTTP port 80. Which will be open all the times. I think, Mozilla supports SOAP, as I read in the book hosted at http://books.mozdev.org BTW, why one cannot write fully functional web-interface for RioCar? Whats stopping it?

why one cannot write fully functional web-interface for RioCar?

The closed source player application.

Anyway, by adding SOAP does not give anything immediately, but indirectly it opens up the door for writing applications which work seamless across firewalls, since it will be based on HTTP port 80.

Which it is kind of hard to imagine many people needing very often, given the nature of the device we are talking about.

I think, Mozilla supports SOAP

It would appear so, yes:

http://lxr.mozilla.org/mozilla1.0/source/extensions/xmlextras/docs/Soap_Scripts_in_Mozilla.html

SOAP sounds a little heavyweight to be put into the kernel itself. You must remember that everything inside the kernel is always loaded and that takes memory away from the player. The Mk1 only has 8MB, the Mk2 has 12MB and the Mk2a has 16MB. It's already pretty tight in there if you want to keep a fairly large memory buffer for the player.
There is nothing stopping you from writing a userspace webserver with SOAP support however. You would get exactly the same amount of functionality as if it was built into the kernel. There is code out there that parses the player database and a few fragments that decode the current play order so it's not impossible to do.

- Trevor

And if something compelling enough comes from this, then it just might make it into Hijack (aka. "the kernel") some day.

Cheers!

it opens up the door for writing applications which work seamless across firewalls

And why is that firewall there in the first place? Hey if we're going to stuff everything though TCP port 80, why bother with the whole complex TCP/IP setup that supports multiple ports and alternative protocols like UDP or SCTP.

indirectly it opens up the door for writing applications which work seamless across firewalls

The only application I can think that I might want this for is so that if I leave my player at home when I go to work, I can still control the music that my cats are listening to.

Could be useful... My dog only likes classical music so I could change the playlist for him when I'm working

- Trevor

Yeah, 'cept there's already a zillion ways to do that.

Cheers

Yeah, 'cept there's already a zillion ways to do that.

(Dang it, we need a "whistling and trying to look innocent" smiley.)