That's what we're going to end up with. If you are using the Async
AppServer, it will be just as you have described, your app will write to
HTTPRespose.out, or something like that, and as long as you have already
told HTTPResponse to send the headers, your data will be sent at the next
opportunity, and the call will not block. If you are using the plain
Threaded AppServer, then the call will block until the data can be sent. If
you are using cgi, it won't blobk and the data will be immediately written
to stdout.
I don't know that we need all of the other Medusa tools. Tell me what you'd
like besides being able to write to a file like object and know that the
data will be sent ASAP and won't wait until your servlet is completely done
and won't block execution.
Jay
-----Original Message-----
From: Terrel Shumway [mailto:tshumway@...]
Sent: Tuesday, January 30, 2001 9:57 AM
To: Love, Jay
Cc: 'webware-discuss@...'
Subject: Re: [Webware-discuss] AppServer Communications
"Love, Jay" wrote:
> Ideally, we want to have the sending stream that servlets write to be a
> buffered object that is written to, and optionally the data can be sent as
> it is written. The same technique could be used for receiving input data,
as
> you have asked. This will not be terribly difficult to do, I just haven't
> gotten to it yet.
>
How difficult would it be to expose all of the medusa tools (producers,
continuations, et. al.) and make things asynchronous throughout? I
would like to be able to say: "here is what I want done, I don't care
how or when you do it." I realize that it is a model most people are
not familiar with. Maybe we could create a class such as
AsyncServlet.... servlet.write would map to channel.push.
Hmm... how does one do an asynchronous SQL query?
My ignorance is showing. Sendfile is an obvious application, but
anything that requires computation requires a lot of work to break
it up. I need to play with this some more.
-- Terrel
----------------------------------------------------------------------------
This e-mail and any attachments may be confidential or legally privileged.
If you received this message in error or are not the intended recipient, you
should destroy the e-mail message and any attachments or copies, and you are
prohibited from retaining, distributing, disclosing or using any information
contained herein. Please inform us of the erroneous delivery by return
e-mail.
Thank you for your cooperation.
----------------------------------------------------------------------------
|