[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