Thanks. After I wrote this message, I feared I might have to roll more than
just my own cookie jar, since I realized I have some web calls that need to
fetch images, and others that have junky legacy unstructured (non-JSON)
returns. But then I noticed Query#setSerializer. So I should be able to do
something like
GetQuery q = new GetQuery("hostname", "/getImage?id=23");
q.SetSerializer(new BufferedImageSerializer());
q.execute(new TaskAdapter<BufferedImage>(new TaskListener<BufferedImage>() {
.. }
to get an image out of a web call that returns jpeg content, right? Very
cool if so.
What sort of connection management is exposed, if any? For example, how
many outstanding GetQuery's can one have at a time? Can I set the limit?
So then GetQuery#execute blocks in the background waiting for a
connection if the limit is currently exceeded?
On Thu, Nov 11, 2010 at 4:02 PM, Greg Brown <[email protected]> wrote:
> Correct. Web queries don't support cookies because they are geared
> primarily towards REST services, which are generally meant to be stateless.
> However, it is possible (and fairly easy) to implement your own cookie
> support.
> G
>
> On Nov 11, 2010, at 6:40 PM, Bill van Melle wrote:
>
> > Is there any kind of cookie jar facility for GetQuery?
> >
> > I didn't find anything in the API, so I'm guessing I have to roll my own
> -- parse the set-cookie fields out of query.getResponseHeaders(), and add
> them to the query.getRequestHeaders() dictionary on each call.
> >
> >
> >
>
>
