[icecast] New YP listing code in icecast2
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
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:
> <listeners>12 20</listeners
> <title>Around the world in a tea daze</title>
> <composer>Simon Posford & Raja Ram</composer>
> <recording_label>Twisted Records</recording_lable>
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.
<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