On Sat, Jul 10, 2010 at 2:25 PM, Jim mack <j...@less2do.com> wrote:
> Thanks, Slava
>
> Would the responder then have a namespace in common among HTTP threads using
> an explicit bind? Sure, thanks.
That's one option, yes, or you can store the data in the responder
directly. It takes a bit of boilerplate at the moment, perhaps at some
point in the future it can be streamlined:
TUPLE: my-web-app < dispatcher data ;
: <my-web-app> ( -- responder )
my-web-app new-dispatcher
<blah-action> "blah" add-responder
... ;
M: my-web-app call-responder*
[ my-web-app set ] [ call-next-method ] bi ;
Then your action can do
my-web-app get data>>
Of course you can name your slots anything, not just 'data'.
> Mostly I was trying to take advantage of the 'look in a chain of assocs
> until you find it' functionality, and thought I could do so with a
> combination of make-assoc and bind fairly cheaply. I had a list of general
> replacements, and specific ones, and ones that change rapidly, and thought
> that chaining would be 'better' than cloning & adding specifics each time.
If you have a sequence of assocs, you can search for a key using the
'assoc-stack' word. This is the word that is used to implement 'get'.
> The only odd problem I've had so far, that I don't have pinned down enough
> to report, is that occasionally chrome and firefox on an xp box where I do
> most development (day job) will clearly be interacting with a different
> webserver. Usually I've been in both, correctly interacting, then make some
> change (or possibly have a crash). I'll restart factor & the primary
> browser (usually chrome) and it initializes properly, but the other browser
> (usually ff), which was open all along, still retains the old in-mem data.
> I can interact with it successfully, and it is clearly the version from
> before the factor restart, but task manager does not list factor. I can
> even close all ff windows and restart ff and still have this happening,
> although as I type that I realize I didn't check the task manager to make
> sure some hidden ff process wasn't keeping it open.
This sounds like a problem in http.server's handling of cache control
headers. A couple of people have reported similar issues in the past
on the Factor web site. Let me know if you find a test case.
Slava
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
