On Wednesday 26 December 2001 12:36 pm, you wrote:
> On Wed, Dec 26, 2001 at 12:57:59AM -0500, Jason Boxman wrote:
> > If design a session to, say, talk to a remote HTTP server and return
> > data, does it make sense to daemonize it or to simply start a new session
> > of (object instance) for each request (I expect to be making hundreds)?
>
> Only hundreds? :)

For me, yes.  Through over its lifetime it could handle many more.  It just 
doesn't live that long yet.  It's still partially working.

> POE::Component::Client::HTTP is a "daemon" component that does
> user-agent things on behalf of other sessions.  The client sessions
> post requests to it, and it posts responses back as they arrive.

Yes, I was looking at that last night.  Unfortunately it returns full 
requests.  My application must stream responses.  See below.

> PoCo::Client::HTTP performs all its requests in a single session.  It
> stores SocketFactory and ReadWrite wheels with their corresponding
> requests.

That's what prompted my single vs many post. :)

> > Is there some logical reason why one method's better than the other or is
> > it simply a matter of personal taste?
>
> Chris Fedde has a good point: network overhead often dwarfs library
> overhead.
>
> That said, the method that must do more work usually takes longer.  If
> you need speed, avoid creating and destroying sessions if you can.
>
> > I used httpd.perl as a template, so I'm employing the latter technique
> > presently.  Is the former or some other technique a better approach?
>
> Two HTTP client components are already written.  Have a look at
> POE::Component::Client::UserAgent and/or ::HTTP.

UA is a wrapper around LW Parallel and Parellel seemed to have problems with 
callbacks (in earlier versions, anyway) and the current version is utterly 
broken with the latest LWP UA.

> > Would it make sense to retain the original SocketFactory listener session
> > and add a single daemonized session to handle requests and post the
> > results to another daemonized 'saver' session?
>
> Wait, listener?  Are you writing a client or a server?

Both.

I'm attempting to write a caching daemon that acts much like a proxy, but for 
a specific client and type of request only.  I originally tried PoCoHTTP, but 
it lacked the streaming support needed for proxying (the local end can't wait 
for the data to buffer and be returned complete).  PoCoUA probably would've 
worked, but when I used it I was using it against a callback-broken LWP 
Parallel, so I jumped ship.  I now use Wheel Run to spawn a child that calls 
LWP UA.  It's... messy.

It probably makes sense to adapt PoCoHTTP and submit a patch for streaming 
support, but when I started this project understanding much of POE was still 
beyond my skill set, so I just limped back to something I could grasp (Wheel 
Run and LWP fork'd).

> -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net

Reply via email to