Re: [Pan-devel] Generating NZB files

[Charles Kerr]

Darren Albers wrote:

> Duncan/Darren, close enough  ;-)

I asked Duncan because he indicated he'd use this feature too,
and because I figured he'd give a very detailed explanation. :)

> If I was to guess what nzbperl has that Pan does not it is a smaller 
> footprint and the ability to limit download speeds.   Fixing 360809 and 
> 102403 resolve both of these issues but neither seem easy.  I took a 
> look at 102403 and the concept that most other apps seem to use for this 
> is to monitor the speed and if it gets above the limit use sleep or io 
> wait to slow it down.   This seemed simple in theory but implementing it 
> was outside my abilities  ;-)

For the throttle, Pan wouldn't need to sleep, just lengthen the time
between getting a "there are bytes waiting to be read" message and
calling socket-impl-gio.cc::g_io_func.  Then we need (1) a mechanism
to compare the overall speed to the user's desired speed and adjust the
throttle accordingly, and (2) new hooks in the Socket interface class
so that the abstract level doesn't rely on GIOChannel.

> On a side note I have been working on a patch for bug 361388 and I think 
> there are two options for handling this that I would like your feedback on:
>
> 1) Save the attached nzb to temp and feed it back into pan.  This has 
> the benefit of creating a new function that saves attachments to tmp for 
> use by external applications.
>
> 2) Decode the attachment inside pan and feed it into  the task manager
> directly.

Hmmm... I see both sides to this and don't know which I prefer.
My knee-jerk reaction is to go with (2) because it's simpler and has
fewer points of failure... but you're right about the side-effects
on 133085.

> I am leaning towards #1 since it would possibly create the 
> infrastructure to close 133085 but I wanted to get your feedback on that 
> in case you felt that it wasn't appropriate to handle it this way.

I'd be happy to read a patch.  Everything leading up to the
on_progress_finished() handler would apply in both approaches,
and even if we go with (2) the rest of the patch can be used for 133085.

cheers,
Charles