[icecast] New YP listing code in icecast2

oddsock oddsock at oddsock.org
Mon Feb 3 15:19:56 UTC 2003



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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.



More information about the Icecast mailing list