> Again, it would be nice to be able to make this reasonably free form > name/value pairs - one extra that has occurred to me is... > > icon_url - to let directoy listings jazz up their displays by permitting > station logos (For speed reasons it's probably nicer for the directory > server to manage teh icons locally...)I'm trying to think of a good way to map arbitrary pairs without impacting searchability greatly and fitting into the backend storage. I'm sure this will be there. icon-url is not a bad idea.> The Number of listeners *has* to remain in, it's up to the directory > server to do whatever they want with it.I disagree. It's fundamentally a different kind of data. It's time-dependent. All the other information is not. 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
>> The Number of listeners *has* to remain in, it's up to the directory >> server to do whatever they want with it. >I disagree. It's fundamentally a different kind of data. It's >time-dependent. All the other information is not. >jack.I'd just like to say that time-dependent information is very important to a listener. Removing it from the directory would be a step backward from where things are today (my opinion). I realize that this has some implications that are not entirely obvious (such as the replication of the directory - how can you manage replication when you have time-dependent information), but that still doesn't change the fact that this information is critical (my opinion) to the directory. I think if you make a directory without any metrics such as listener counts (or something that represents listener counts) or current song titles, then well,it really loses alot of appeal (my opinion) perhaps a compromize of both time-dependent and non-time-dependent information ? I also don't like the idea of a client sending out 100 requests to all listed servers to say, "Hey, what are you playing". Flashbacks from RadioSpy... oddsock --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
oddsock wrote:> > I'd just like to say that time-dependent information is very important to a > listener. Removing it from the directory would be a step backward from > where things are today (my opinion).I aggree with oddsock on this one. This is really very important to the listeners. Take a net broadcast of a regular station, he'll only see live as genre, and then he woulnd't know what's playing. Maybe the station's description says it's a techno station, but he bumbs into a speech-only program. Then he'll be disappointed in the station, even though what really happened is that he bumped into a speech program. It really seems, that you can not describe the contents and nature of a stream with static data, as (fortunately enough) people always stream something different. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
I am not averse to making time-dependent information available. But it does not fit in this model. We have to change the model to accomodate time-dependent information, and I'm not willing to use the model that has been use in the past, which was to treat both types of information as identical and just accept all the inconsistencies and problems. And easy solution is to let clients query for this data from the server. It solves the problem (access to the time-dependent information) and makes sure that the information is always accurate.> I also don't like the idea of a client sending out 100 requests to all > listed servers to say, "Hey, what are you playing". Flashbacks from > RadioSpy...RadioSpy suffered from many problems unrelated to this model of doing things. What we're doing is not exactly the same. That being said, let's disucss the pros and cons. What is your objection to making the server responsible for time-dependent data? 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.