Some information about the HTTP interface (off the top of my head, so it may not be completely accurate):
The first thing that the Receiver asks for is "/tags". This is just a list of the database field names. You can hand over /empeg/var/tags.
The next thing that the Recevier asks for is "/layout/en_UK/index". This is the index of layout definitions
The index file contains the layout definitions, one per line. The Receiver will pick one and download it. The file contains the server-relative URI for each layout definition.
You'll probably want to stash these in /empeg/lib/layout and hand them out from there. Wherever the Central keeps them is probably a good idea, for consistency.
Then, there are various other things that the Receiver will ask for:
This is the tags for a particular FID. It's exactly the same format as in the empeg's "database" file.
This is the MP3 content for a particular FID. You'll need to be able to satisfy "Range:" requests, since the MP3 download is in chunks.
If you specify the FID for a playlist, then this returns the FID entries for the immediate children. See this
for more information. A variables that you can try is "_extended" for controlling the format. _extended=0 (the default) returns the binary format (i.e. the content of the *0 file). _extended=1 returns the format detailed on the linked page. It might also support _extended=2 and _extended=3, depending on whether they got turned on for the final release (one of them was a nice HTML-rendered list).
The Receiver wants the (flattened) list of descendants for a particular playlist. It'll generally ask for /list/100 soon after it starts.
You can ask for this list to be shuffled by passing "_shuffle=1" (or was it _shuffled, or shuffle?).
Used for the Receiver search screens. It'll only ask for "artist", "title", "album" (or was it "source"?) and maybe "genre". I don't remember. I detailed the response format in a PM conversation with Tony. Maybe he can repost it here.
The only regexes supported are character classes (i.e. simple lists of characters in square brackets). A wildcard (i.e. dot-star) suffix is implied.
Return the list of FIDs found by choosing one of the entries returned from the above query. Takes the same _extended variable as described above.
The Receiver does not support "Transfer-Encoding: chunked". You should(preferably) return a Content-Length header. You will always have to use "Connection: close" semantics.
The Receiver will never pipeline requests.
If you don't respond to a query within a sensible time limit, the Receiver will retry its request. If you're going to take a long time to process a request, consider waiting for the retry and handing back the data then, IYSWIM.