[Interopcast-general][icecast-dev] about translating documentation, but not only documentation.

[Michael Smith]

On Friday 01 August 2003 18:53, Arnaud Ebalard wrote:
> >User/Admin documentation, on the other hand, is something that we
> > desperately need. I really do want to try and integrate the documentation
> > you and your students have written, but it's difficult - you haven't
> > exactly gone to a lot of effort to send the icecast developers patches.
> > It's also (taking a quick look at your cvs repository) looking quite
> > difficult to just mass-merge everything from your sources, since you've
> > reorganised everything.
> >
> >I'm _very_ interested in getting your documentation into mainline icecast,
> > and merging back those code changes you've made that are appropriate.
>
> We commented our sources and made documentation (user & developper) on
> what we
> wrote. I understand it is difficult to merge our changes into your codes :
>
> -  Format module and buffer module (now known as streambuf) were totaly
> rewritten in
> order to add new capabilities, modularity and improve performances. It's
> (I think) easier
> to add new ogg formats because, there's a recognition of ogg
> encapsulated format which
> transparently toggle to the good plugin function (speex, vorbis (but we
> could easily add
> fLaC, theora, ...)). The new streambuf module works was rewritten to
> allow less
> memory allocations and reallocations

What new capabilities were added by these changes? The format handling was 
already quite modular. Splitting out ogg-encapsulated-format handling is a 
good idea - it was always planned, but (because there are, as yet, no 
streamers that will send non-vorbis ogg formats to icecast) we never 
implemented it.

Replacing the refbuf module with your 'streambuf' is not neccesarily a win. It 
changes the behaviour quite significantly (i.e. it's not purely a performance 
improvement) - my choice there would have been to optimise refbuf for that 
particular usage (specifically, skipping some of the unneccesary locking, and 
performing allocation out of a shared pool). I never did that because 
profiling showed that these functions weren't having a significant 
performance impact.

>
> -  Source and Slave modules have been remodularised (does this word
> exist?).

In what ways? Since you've completely reorganised/moved everything, it's very 
difficult to see what changes have been made (and even harder to reintegrate 
any of them) - if you give a clear description of what you've changed and why 
it's worth doing it that way, it gives us much more of an incentive to try 
and merge your changes.

>
> -  Three of us worked on the new IcecastAdmin part and they wish to
> continue their work
> in september. The IcecastAdmin part is at the moment a standalone
> process that listen for
> securised connections (OpenSSL) from browsers and allow the client to
> modify the
> XML configuration file of Icecast. It could then merge into Icecast as a
> thread and be used
> to make hot securised modifications to the Icecast server.

Adding in SSL support for the admin interface is very interesting, but I'm 
unsure from this paragraph why theyour admin program is a seperate process, 
and not part of the existing admin interface.

>

> There is another possibility if you could find some time to spend on it
>
> : take our version, try
>
> to add the main patches from last months and make it available to people
> for tests. If this
> give good results, you could take the time to add some of our changes.
> It's only an idea, but
> it could allow you to see if our changes are interesting and valuables
> things or not.

Unfortunately, because you've reorganised so much of the sources (even where 
you haven't made substantive changes) taking any patches out from your 
sources is extremely difficult. Perhaps you'd care to contribute some 
individual patches - that's the way open source development is usually done.

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.