On Fri, Jun 30, 2000 at 09:30:09PM -0700, Jon Scarborough wrote:
> There's one gotcha I'm aware of that I don't think is covered by the design
> you describe here.  The user can open a new browser using File/New/Window
> (in IE) that shares the same session as the origional browser.  If the user
> has two browsers open that share the same session, wouldn't it be possible
> for one Screen stack to effectively step on the other one?

Yes that is a problem. In fact if the user starts doing this there are
other problems. Two browser windows on the same Turbine session opens
the possibility of two requests being processed simulataneously and
accessing the same session objects. In general these session objects are
not thread-safe.

There is a mechanism (the session_access_counter) for ensuring the user
gets an error if they try this, but this is not always appropriate.

> I've partially solved this problem in my code using the concept of a
> "module."  Each set of connected screens stores it's working set of data in
> its own module, so the user can be doing something different in one browser
> without stepping on the state information of the other.  

I dont like the added complexity of this, especially as it becomes a
maintenance hazard as you have to know which elements of the site you
can bring into an interaction, and which belong to another module.

> This still doesn't
> solve the problem completely though, in the case where the user is doing
> concurrent identical tasks in each browser.  I think I can solve that
> problem by attaching some sort of "transaction id" to each independent
> context using a hidden form field or by doing a URL fixup, but I haven't
> tried that yet.

That still doesn't solve the problem - if you open the the new window
with right-click 'Open in new window' on a link you end up with both
frames having the same "transaction id" so you're screwed again.

Ideally the browser would transmit a unique "frame id" in the request
headers - but it doesn't.

I guess given that the only robust solution is to disallow multiple
browser frames with the session_access_counter.

> Does this help at all?  If anyone is interested I could post more details on
> what I've done so far.  The code itself is really raw right now, and overall
> not nearly as elegant as the stacking idea.

I'm still interested in what you've done is you think it could
improve my ScreenStack API.

-- 
Sean Legassick
[EMAIL PROTECTED]
                                  homo sum: humani nihil a me alienum puto



------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?:           [EMAIL PROTECTED]

Reply via email to