Re: [PATCHES] Smartjog PatchDump

Niv Sardi <[email protected]>
Newsgroups gmane.comp.audio.icecast.devel
Organization GZi
Message-ID <[email protected]>
(answering both mails in one, as they call back each other)

Michael Smith <[email protected]> writes:
> Can you file bugs and attach the patches to them in our bugtracking
> system? http://trac.xiph.org/

Sorry, I really don't feel like creating 3x tickets right now =)

> Mail dumps of patches are pretty much guaranteed to not get merged.

Understandable. 

> From a very quick look at a couple of them: in amongst the actual
> changes, there are lots of formatting changes, and things like
> additions of "XXX: ..." comments that don't say anything helpful -
> these will need removing before the patches are really reviewable.

hum, I tried to keep those as separated as I could, but might be, it's
about 2 months of developement that is dumped here.

> A higher-level description of what you're attempting to accomplish
> with these patchsets would also be very helpful - but much more detail
> than "performance and reliability".

I actually dumped these patches at my last day working for SmartJog, but
they already have a new guy (Remi) to take over maintainership. The main
idea was to be able to continue working on IceCast while out of
contract. I still have a lot of vectors where I'd like to see the
IceCast code go:
* Add refbuff pools.
* Use libCURL for everything (drop httpp).
* Implement a better stats system (stats are actually a HUGE perf
bottleneck). We can do stats without locking.
* Merge connection.c and slave.c (it's not so far off now).

There are a few more patches needing review to add new formats, but
these need to be released later on. The first thing I tried to do was to
get get_buffer() to have some context stability when called from a
source or a slave (especially the first call), especially for formats
that need to parse a header there. Before the connection re-vamp, what
we got in the refbuf at first call was more sheer luck than anything.

Re-working the connection path, got me to break the way ShoutCast was
handled, I then re-implemented the support in a less hackery way.

A bit later down the track, I needed POST support for testing, that was
easily implemented (patch 14).

Then I got interested in improving the number of accept() per second. In
order to do so, I splited out the connection process in 2:
* accept() and push to a queue.
* process connection and pass it over once auth'd and validated (2 pass:
http validation, and logical validation)

right now, the process phase is timeouted and re-entrant for the first
pass only, the parts of the second one that can be slow (I'm not sure
there are) should get a liftup.

> On Fri, Jul 30, 2010 at 10:43 AM, Romain Beauxis <[email protected]> wrote:
>> Le vendredi 30 juillet 2010 12:25:48, Michael Smith a écrit :
[…]

> New contributors would be very welcome.

Great !

>> If no one has time to review the patch, perhaps giving Niv Sardi a commit
>> access is the right answer ? Not necessarily for an immediate stable release,
>> but, hey, commiting them somewhere would help users testing, reporting, etc..
>
> Given the number of issues with the patches as they stand, directly
> giving access right now would seem counterproductive.

Agreed, more on that later.

> In Niv is
> interested in becoming part of the icecast community (rather than just
> dumping a pile of patches on us), then in the medium term that would
> be great.

As Romain said, SmartJog is interested in maintaining the patches (they
use IceCast daily), are truely opensource friendly, and will have a guy
(Remi) on the job. On my side, I'd love to see this work merged, and to
continue getting things in IceCast.

Can we cut things up a bit ?

the first patch is a direct feature patch, (not even originaly from me),
maybe that can go in ?
 [PATCH 01/31] Hack to support IPhone streaming

Then you can ignore this one, it's actually only needed much after.
[Thread connection]
 [PATCH 02/31] introduce thread_cond_init and refrase thread_cond_create.

This one is clean:
[Get rid of the {WARN,INFO,DEBUG,..}n macros]
 [PATCH 03/31] LOGGING add non arg-counted macros.

This part is the first cleanup:
[simplify header parsing, inspired by source.c code]
 [PATCH 04/31] UTIL, add find_eos_delim and use it to simplify util_read_header (pending con)
 [PATCH 05/31] connection: make process_request_queue use util_find_eos_delim
 [PATCH 06/31] connection.c: use util_find_eos_delim to simplify _handle_shoutcast_compatible

Can we look into getting those ones in ? it's a feature and a bit of cleanups

Cheers,
--
Niv Sardi

_______________________________________________
Icecast-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/icecast-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.