[icecast] a new directory service

[Asymmetric]

At 11:31 PM 9/16/2001 -0600, you wrote:

>So I've been doing some research and thinking here and there about what
>a _good_ directory service for icecast would be like.  I'd appreciate
>some feedback and some discussion on this topic, before I start putting
>a lot of effort into developing it.
>
>First off, I think getting rid of # of listeners is a must.  It just
>creates a self-fulfilling prophecy and encourages cheating.  I think the

I sympathize with the anti-cheating attitude.. but I'm against any 
enforcement of this sort of policy.  That seems just horribly MySQLish to 
me.. It's trivial to include that information in the server, and equally 
trivial to leave it up to the server admin to enable/disable that 
functionality.

It may be meaningless to most listeners, but having it tracked (and 
public-domain) is valuable to admins and marketing types alike, if your 
goals lean that way.

>best way to facilitate finding streams that you really want to listen to
>is to make the information sortable, searchable, and filterable etc.

Absoloutely a must.  The "genre" field is a reasonably good idea for this 
stuff, but I think it requires a different approach.  Let the listeners 
define their own genres, based off artists played on the stream or 
something to that effect.  This could be integral to the server software, 
or written into a PHP (or insert-your-script-language-of-choice) front end 
(thus keeping the server in the role of a server, and not a server-client 
hybrid.)

>DIRECTORY VALUES
>================

>type
>         type of the stream
>         ex.: audio/mpeg or application/ogg

I find this pretty irrelevant myself, especially from a user 
perspective.  It can (and should) be indicated on the specified URL, and if 
you'll pardon me for saying, seems to violate the "spirit" of your 
reasoning behind wanting to remove listener counts.  I think the only 
people that would give a damn about this are people who endorse a certain 
technology over another (Mpeg vs. ogg vs. wma vs. whatever).

I don't think it's terribly interesting to listeners.. if they have a 
client installed that supports that MIME type, then it will play.. if not, 
then it will tell them that they don't have the appropriate software 
installed to listen.  Users are used to this interface and trained (for the 
most part) to know how to handle it, so I don't think it's a problem.

>ttl
>         time to live.  number of minutes  an entry is valid for.  subsequent
>         directory changes will refresh this value.  when the value
>         reaches 0, this entry will be removed.
>         ex.: 5

I don't think this should really have anything to do with the directory 
itself.  It should be a transparent server-side configuration 
parameter.  If clients can set it then you just end up with clients that 
connect once with 9999 (or whatever your max value is) and then never 
connect again to spam the server.. fill the directory up with all kinds of 
garbage.

>auth
>         authorization string.  this is a md5sum of of some
>         random data.
>         ex.: echo 'jack at xiph.org|Jack Moffitt|password' | md5sum

What is the purpose for this?  Is one of the other mentioned fields going 
to be dependant upon this being correct?

I think all we really need in the current yp listers is a better search 
facility, as you've mentioned.  I would also like to see (not only in the 
yp, but really in icecast as well) a more robust template facility, like 
shoutcast has.  It's very easy for me to give my mirror maintainers a 
template file that they can use to generate their stats for inclusion into 
my mirror list if they're using shoutcast; using iceast is a hassle 
involving either modifying the current templates and screwing up god knows 
what, or writing scripts to hit one of the current status pages and then 
post-processing the output before including it on the webpage.

--- >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.