[icecast] a new directory service

[Jack Moffitt]

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

That's what logs are for.  This is not a public log.  Things are not
tracked over time.  The information is only valid for a 'ttl' period.
>Froma marketing angle, you might even argue the other way, that people
don't want this information published (except to advertisers).

> >type
> >         type of the stream
> >         ex.: audio/mpeg or application/ogg
> 
> I find this pretty irrelevant myself, especially from a user 
> perspective.  

It's not for the users.

> It can (and should) be indicated on the specified URL,

Go read a basic document on Internet Standards.  Encoding meta
information (especially type) in a filename or URL is broken and wrong.

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

Or people who value freedom and want to use only Free technology.  This
serves a few purposes though.  a) a directory admin could lock this
field to a single value, doing service for only Vorbis for example.  b)
supporing legacy and discontinue or nonupgradeable products that are MP3
only will need to know.  

And of course, if you think that people don't care about quality at
lower bitrates, then I disagree with you.  I would chose a Vorbis stream
over a MP3 stream any day, if the rest of their attribute were similar.  

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

We want clients to be able to set it, and if it's documented, they will
likely set it responsibly.  You don't want someones commercial stream
that is on expensive bandwidth and never goes down to hit the server as
much as everyone else.  This will help scaling a bit I think, as people
who are knowledgeable about how things work can change the default
values to be more efficient.

This also brings up another reason to ditch listener counts, and that is
that it's TIME DEPENDENT.  All of these other values are not time
dependent.  They will be valid the entire ttl, or until the server goes
away.

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

This string is set buy the listing client.  The server will contact the
server for that URL and a compare process will happen.  If the entries
match, It will get listed.  Clients do not have access to this value,
except listing clients which set it.  Once you're in the directory,
updates must contain this value too.  This prevents people from forging
your information, or hijacking your entry.

> yp, but really in icecast as well) a more robust template facility, like 
> shoutcast has. 

We had templating a good long while before shoutcast did.  And people
did some crazy things with it.  Hardly anyone ever used it, and it fell
into disrepair.  I'll keep this in mind for icecast 2, which already
outputs XML documents.

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

You won't need this for icecast if that's your use.  You can use request
and parse the stats.xml which will dump all stats on the server.  You
can also connect as a stats client, which will give you a dump, and then
realtime stats updates while you stay connected.  And that _already_
works :)

jack.

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