well, don't get me wrong, I am not generally opposed to progress, but speaking as a coder of source clients, providing yet another authentication mechanism is a bit frustrating.... I guess it wasn't too bad having to deal with Shoutcast/Icecast/Icecast2 specific connection protocols (yes they are ALL different!) but I am NOT going to support Shoutcast/ICecast/Icecast2 (ICE Login)/Icecast2 (HTTP Basic Auth)/Icecast2 (HTTP Digest)... now probably the correct answer to this is to get libshout to do all this connection song-and-dance....but in order for *me* to use it, it must at least support : - Connection protocols for Shoutcast/Icecast/Icecast2 (all variants) - Metadata updates for all server types (this *includes* inserting the metadata into the vorbis stream for icecast2 *and* Shoutcast style metadata updates) last I checked (and granted libshout has been getting a lot of commits of late) this stuff wasn't in there... just my .02 oddsock At 01:21 PM 8/18/2002 +1000, you wrote:>At 12:24 AM 8/18/02 +0200, you wrote: > >Hi, > > > >I just updated my CVS copy of icecast2, and saw that the default login > >protocol now is HTTP basic authentication, which ICE/1.0 still > >selectable through the config file (by inserting an > ><icelogin>1</icelogin> element). > > > >My question is: what is the intended future login protocol for icecast2? > >Will ICE/1.0 be phased out in favour of HTTP basic auth? > >ICE login is deprecated. I don't intend to remove it in the immediate >future - but as you may have noticed, the <icelogin> thing isn't documented, >and that's deliberate. > >HTTP Basic auth is what will be available for beta1, and probably the first >stable release. HTTP Digest auth is something I'm considering for the >future - but if that gets added, it'll be optional (so you'll be able to >configure icecast to require it if you want better security, or just leave >both available). Login will remain using some form of HTTP authentication, >however. > >By the way - a beta1 release of icecast2 is planned for the near future >(probably in a week or so, depending on testing in the next few days), >so if you think darkice (assuming I'm remembering correctly and that's >your client) is stable enough, send me a short (~one sentence) description >and a URL to include in the list of source clients in the documentation. > >That goes for anyone else writing source clients, too. > >Mike > >--- >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.<p><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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
smoerk wrote:> > I guess it wasn't too bad having to deal with > > Shoutcast/Icecast/Icecast2 specific connection protocols (yes they are > > ALL different!) but I am NOT going to support > > Shoutcast/ICecast/Icecast2 (ICE Login)/Icecast2 (HTTP Basic > > Auth)/Icecast2 (HTTP Digest)... > > there should be only one login protocol for icecast2. are there any > advantages of HTTP Basic Auth over ICE/1.0? There are several programms > which have to be changed: > > Server: Icecast2, Jroar > Clients: Darkice, Ices2, OddcastDSP, Ostream, Oggcast (PD external),... > > Not only the coders have to change, but people have to download (, > compile) and install the new software. So we as developers should agree > on one login protocol.Well, Icecast2 was never released so far, neither as an alpha preview nor a beta (which, afair, will happen soon, though). People always had to get it through CVS... I find even harsh changes like this, changing the login protocol, should be expected until it's officially beta. How I understand this, http basic auth will be default for Icecast2, while still offering the deprecated ICE Login for compatibility reasons (e.g. for older source clients that only support MP3 streaming, which also don't enjoy any further developement). My theory, however, has a flaw. It doesn't quite fit when ICE Login from Icecast1 and -2 are different. ;P Can someone tell me whether this difference is there on purpose, or simply because Icecast2 is still in its relatively early developement stage? <p>Moritz --- >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 guess it wasn't too bad having to deal with Shoutcast/Icecast/Icecast2 > specific connection protocols (yes they are ALL different!) but I am NOT > going to support Shoutcast/ICecast/Icecast2 (ICE Login)/Icecast2 (HTTP > Basic Auth)/Icecast2 (HTTP Digest)...Looking at the good side: HTTP Basic auth is at least documented in the HTTP RFC :) <p>Akos --- >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:> well, don't get me wrong, I am not generally opposed to progress, but > speaking as a coder of source clients, providing yet another > authentication mechanism is a bit frustrating.... > > I guess it wasn't too bad having to deal with > Shoutcast/Icecast/Icecast2 specific connection protocols (yes they are > ALL different!) but I am NOT going to support > Shoutcast/ICecast/Icecast2 (ICE Login)/Icecast2 (HTTP Basic > Auth)/Icecast2 (HTTP Digest)...there should be only one login protocol for icecast2. are there any advantages of HTTP Basic Auth over ICE/1.0? There are several programms which have to be changed: Server: Icecast2, Jroar Clients: Darkice, Ices2, OddcastDSP, Ostream, Oggcast (PD external),... Not only the coders have to change, but people have to download (, compile) and install the new software. So we as developers should agree on one login protocol. <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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 10:23 PM 8/18/02 -0500, you wrote:>well, don't get me wrong, I am not generally opposed to progress, but >speaking as a coder of source clients, providing yet another authentication >mechanism is a bit frustrating.... > >I guess it wasn't too bad having to deal with Shoutcast/Icecast/Icecast2 >specific connection protocols (yes they are ALL different!) but I am NOT >going to support Shoutcast/ICecast/Icecast2 (ICE Login)/Icecast2 (HTTP >Basic Auth)/Icecast2 (HTTP Digest)... > >now probably the correct answer to this is to get libshout to do all this >connection song-and-dance....but in order for *me* to use it, it must at >least support : > >- Connection protocols for Shoutcast/Icecast/Icecast2 (all variants) >- Metadata updates for all server types (this *includes* inserting the >metadata into the vorbis stream for icecast2 *and* Shoutcast style metadata >updates)Sorry, I forgot to reply to this the other day... You're right that it doesn't provide all the metadata stuff that you might want - but don't let that by itself be a reason to stop you from using libshout. libshout can be used in two ways - as a complete solution for the entire protocol (for which it is somewhat limited, as you note), or _just_ for login. After login, you can just use shout_send_raw() (I think that's what the function is called - something like that, anyway) to send a buffer directly to the socket. This is what ices2 does, for example. This lets the login protocols (which are, I agree, quite excessively varied) be abstracted out behind a single interface, but still give you all the control you want for the actual stream (for which you obviously already have code). Mike --- >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.