[icecast-dev] Icecast 2: planned stuff.

[Michael Smith]

On Sunday 02 February 2003 23:13, Pierre Amadio wrote:
> Hi there.
>
> First, some words about what the context is over here.
>
> I'm a member of a french working group assembling several non profit
> organisation members that intend to help promoting free software usage,
> and in this case ogg vorbis and icecast.
>
> http://www.aful.org/gdt/interop/casRadioFrance.html
>
> Non profit organisation included in this group are Abul
> (www.abul.org), Aful (www.aful.org), April (www.april.org)
> and i may forget some :)
>
> Our main concern in this project is to be able to show there are free
> software solution that can stream audio data and to improve those
> solution to be as easy to use and install as possible.
>
> One of our member works in a computer school and intend to propose
> icecast improvement as a student project that will count something
> like 6 student.
>
> Right now several ideas of improvement have been thinked about, lots
> of those existing in icecast 1.
>
> - multi language possibility.

That'd be great - and something particularly well suited to a group of people 
from a non-english speaking country :-)

> - syslog logging

Not sure if that's really all that worthwhile. What's the reasoning behind 
this one?

> - kicking client function.

Yes, I suppose this would be good. 

> - switching player client to an other mountpoint function.

Already done. (mostly).

> - switching source client to an other mountpoint function.

Could be done, but note that if the source gets disconnected (e.g. because of 
network errors), most sources will automatically reconnect on the old 
mountpoint. Whether that _matters_ is another question.

> - having a way to compute a network quality indicator for each clients.
> - using this indicator to automatically switch player client to an other
> mounpoint streaming same data in lesser quality in case of bad network.

These are quite a lot of work, but it's interesting in many ways, and would be 
a wonderful feature to have. It's also a substantial amount of work that 
wouldn't really touch the rest of the system, so it's particularly well 
suited to being done by an independent group.

> - having a nice graphical or web interface around this.

This is something I'd like, but my HTML design skills are somewhat lacking (it 
always comes out looking ugly :-)

> - packaging and 'install it for dummies' solution.

This is already being done on win32, but RPM and DEB packages for linux 
systems would be good.

>
> I'm a bit worried about how can our effort be coordinated with yours.
> That's the reason i would be please to know what are the improvement you
> already plan to code, and those you don't.

My plan doesn't really extend in any concrete way very far - but if we know 
people are working on one feature, then we can stay away from that part of 
the code until your bits are ready. 

I'm happy to answer questions about whether I think particular features are 
useful or appropriate. I don't think merging changes will be a major problem.

>
> How would you imagine our collaboration could be done ? Do you think we
> could ask you to host mailing list,web,cvs and stuff or would you prefer
> we use our own solution ?

We have two mailing lists here (icecast-dev at xiph.org is entirely appropriate 
for this sort of thing).
If you want your own private website/mailing list for your group, then you 
should set that up yourself. However, you're welcome to use our existing 
infrastructure for development discussions.

As for cvs - we're generally happy to give access to people who have shown an 
ongoing interest in developing, and have submitted at least a few 
high-quality patches. Again, however, if you want to have your own private 
server, you'd have to provide it yourself - and we won't give cvs access to 
people who have not proven their ability to contribute sufficiently good 
code.

>
> > The only supported way of doing this is by fetching /admin/stats.xml (or
> > /stats.xml on slightly older versions). This is structured in such a way
> > that getting the relevent data out is easy. Also, the xsl templates
> > (which are automatically applied to this xml data) can be used to create
> > a web interface (with some limitations - but not too many).
>
> /admin/stats.xml looks exactly as what i need for having live
> information about server status. What about a POST or GET method to be
> able to change configuration settings and send commands (like kicking
> and improvement idea above) to the server ?

There are already a few commands implemented - they currently use GET. 
However, another useful small project would be to extend the HTTP parsing 
infrastructure to be able to cope with POST requests. The current code has a 
lot of duplication for each individual admin command, extending this to a 
more powerful and generic admin system would be a good project.

>
> > Documentation help would be very welcome - just send anything to me, or
> > to the mailing list.
>
> May be Ciaran Anscomb (http://www.6809.org.uk/kja3/ices2-howto.shtml)
> and/or Kerry Cox (http://quasi.ksl.com/icecast/) would be interested
> joining the effort too. Would it be possible to have a cvs documentation
> module writing acces somewhere ? If not, i guess savannah
> (http://savannah.gnu.org/) would be a solution but having the most
> centralised stuff as possible sounds like a good idea.
>
> What format (raw text/html/docbook/whatever ?) do you think would be the
> best choice to use ?
>

I think docbook would probably be the best approach to take with this. 
However, if there's a compelling reason to use something else, that's 
generally fine.
CVS access for documentation works the same as for writing code - if you've 
contributed good stuff, we'll generally give you access. Until then, docs 
should come to the mailing list, where they can be discussed, etc.

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