I have just committed this code to CVS, and here is more information about it for those interested : - the spec that I went off of for the protocol can be found here -> http://www.oddsock.org/icecast2yp/spec.html - since icecast2 now needs to potentially connect out to yp servers for communication, libcurl has been added as a dependency...I used curl 7.9.8... - I also have currently implemented a yp server running at http://www.oddsock.org/cgi-bin/yp-cgi. This follows the protocol I defined above (as far as I know at least). and the default icecast.xml that is in CVS is configured with that yp server..feel free to implement your own yp server and add additional entries to <directory>..I think icecast2 supports an arbitrary number of directories (within reason) :) - you can browse the directory here-> http://www.oddsock.org/icecast2yp/ - I still consider this all "under test"..so please help test it all out, and identify any and all bugs. - I've created a tarball and a win32 distribution and stuck them under http://www.oddsock.org/icecast2yp/test/ - if you are having any trouble, please turn on debugging (log level 4) in icecast2 and look at the error logs... oddsock <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Sun, 2 Feb 2003, oddsock wrote:
| I have just committed this code to CVS, and here is more information about
| it for those interested :
This is great!
But I have a few wonderings:
I'm suprised that the HTTP/GET method of notifying YP servers is still
preferred. According to this protocol, we're still limited to essentially
title/author, listeners, etc. In other words, we're still constrained by
what information is accepted by the YP server.
I've been thinking that a more XML-like approach could offer more
flexibility on the part of what a icecast server can/wants to submit to a
YP server, and out of that, what a YP server can/wants to accept, store,
and then show to web browsers that search it's database.
For instance, in the OGG "ID3" tag format, you can define any
arbitrary
field names in the tag that you want - but you still have several
standardized ones such as ARTIST, TITLE, YEAR, etc. but you're still left
with the flexibility of defining tags that carry other perhaps useful
information... this is what I'm referring to re: extensible YP server
data.
o a icecast update to a YP server could look like so:
<xml>
<stream_ID>3421</stream_ID>
<listeners>12 20</listeners
<artist>Shpongle</artist>
<title>Around the world in a tea daze</title>
<composer>Simon Posford & Raja Ram</composer>
<recording_label>Twisted Records</recording_lable>
<recroding_catID>TWSCD16</recording_catID>
<year>2001</year>
</xml>
<p>And then the YP server can take that, parse out what it specifically
can
work with and throw away what it can't.
So ultimately, if all of those above example fields were accepted by the
YP server, i would output something like this to web browsers:
Radio Spliff is currently playing Shpongle - Around the world in a tea
daze. Released in 2001 by Twisted Records (TWSCD16). Composed by Simon
Posford & Raja Ram. There are currently 12 listeners out of 20.
I guess you may get my drift. I'm just saying that the capacity and
opportunity exists to make YP servers more edcated about what's playing
out there :) why not take advantage of it?
/dale
--- >8 ----
List archives: http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
At 01:26 PM 2/2/2003 -0500, you wrote:>I'm suprised that the HTTP/GET method of notifying YP servers is still >preferred. According to this protocol, we're still limited to essentially >title/author, listeners, etc. In other words, we're still constrained by >what information is accepted by the YP server. > >I've been thinking that a more XML-like approach could offer more >flexibility on the part of what a icecast server can/wants to submit to a >YP server, and out of that, what a YP server can/wants to accept, store, >and then show to web browsers that search it's database. > >For instance, in the OGG "ID3" tag format, you can define any arbitrary >field names in the tag that you want - but you still have several >standardized ones such as ARTIST, TITLE, YEAR, etc. but you're still left >with the flexibility of defining tags that carry other perhaps useful >information... this is what I'm referring to re: extensible YP server >data.well, the current implementation of the YP server does not prevent such things from being implemented....although, honestly, the reason the YP server was designed as such was because I didn't feel it needed that type of detail...I think the existing YP approach was just fine for what it needed to do, building a next-generation YP was something that Jack Moffitt wanted to do, and had gone quite a bit on the design, although when all was said and done, there was noone really to implement it...or noone would, or noone had time, you pick the reason...Have a working YP I thought was pretty critical to icecast2 (especially since the icecast1.x one kinda bit the dust) and rather than reinventing the wheel, I thought it best to simply pump up the tire....>so a icecast update to a YP server could look like so: > ><xml> > <stream_ID>3421</stream_ID> > <listeners>12 20</listeners > <artist>Shpongle</artist> > <title>Around the world in a tea daze</title> > <composer>Simon Posford & Raja Ram</composer> > <recording_label>Twisted Records</recording_lable> > <recroding_catID>TWSCD16</recording_catID> > <year>2001</year> ></xml>XML is not really suited for this type of request, you don't need structured data for YP communication, you just want a varying number of parameters, which is currently possible given the current implementation. <p>>And then the YP server can take that, parse out what it specifically can>work with and throw away what it can't.another thing about the design...The YP server needs to be fast, efficient and scalable...XML is extensible, but not terribly fast and efficient...>So ultimately, if all of those above example fields were accepted by the >YP server, i would output something like this to web browsers: > >Radio Spliff is currently playing Shpongle - Around the world in a tea >daze. Released in 2001 by Twisted Records (TWSCD16). Composed by Simon >Posford & Raja Ram. There are currently 12 listeners out of 20. > >I guess you may get my drift. I'm just saying that the capacity and >opportunity exists to make YP servers more edcated about what's playing >out there :) why not take advantage of it?just because you can do something doesn't necessarily mean you should. Adding additional attributes to the listing is pretty much a trivial task, but simplicity rules when displaying and searching YP servers... well, that is what I think anyways.... thanks for the input though...you ideas are good. oddsock <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.