Ticket #4 (assigned enhancement)

Opened 6 years ago

Last modified 6 years ago

Allow saving and restoring the browser state.

Reported by: bringert Owned by: sof
Priority: minor Milestone:
Component: component1 Version:
Keywords: Cc: will@…

Description

---------- Forwarded message ----------
From: Will Thompson <will@willthompson.co.uk>
Date: Thu, May 22, 2008 at 8:00 PM
Subject: Patches for HTTP.Browser to allow saving and restoring the state.
To: bjorn@bringert.net


Hi,

My application needs to go through a bunch of authentication steps
before it can make any useful requests.  Currently, I can either do all
the steps every time, or rebuild the browser state manually by saving
getCookies and getAuthorities; the attached patches add a function
browseS that allows the initial state of the browser to be given by the
user, and returns the final state along with the BrowserAction's result.

(This also includes the previous patch I sent, removing an 'error' call
from defaultBrowserState, as it is a dependency of the new patches.)

Is sending you patches directly the right thing to be doing?

Thanks,
--
Will

Attachments

preservable-browser-state.dpatch (14.3 kB) - added by bringert 6 years ago.
Will Thompson's preservable state patch

Change History

Changed 6 years ago by bringert

Will Thompson's preservable state patch

Changed 6 years ago by bringert

  • cc will@… added

I haven't applied this yet, since I'm unsure about the proper API, or at least the function name. If we compare Network.Browser to Control.Monad.State, the existing browse function is like evalState, and Will's browseS is like runState, but with the elements of the returned tuple reversed.

Another way to make it possible to do browser actions occasionally would be to make a MonadIO BrowserAction instance. This is the approach taken by for example Network.CGI.

Perhaps the most reasonable would be to do both?

Changed 6 years ago by bringert

Oh, I forgot to say that both of the above could easily keep the connection pool alive for too long. This could get us back to the old resource exhaustion problem.

Changed 6 years ago by sof

  • owner changed from somebody to sof
  • status changed from new to assigned
Note: See TracTickets for help on using tickets.