[Zope] More on understanding conflicts

[Chris McDonough]

On Dec 21, 2005, at 11:38 AM, Dennis Allison wrote:

>
> Chris,
>
> You asked about frames a while back and I responded in the  
> affirmative.
> I am sure I mentioned that we use frames and framesets and  
> explained that
> we use a bit of Javascript to manage loading individual frames  
> rather than
> loading the entire frameset whenever possible.

Eek.  Sorry, I don't remember this.  Context is hard to keep over the  
course of several weeks/months, of course.  And my brain is going  
with my age.  I don't mean to be a nag (really, I understand this is  
hard), but I asked two emails ago "do you use frames?" and you didn't  
answer that question directly in your response at all; only by way of  
teasing it out of you by asking if it was an IFRAME in a followup was  
the fact that this app is a frame-based one re-revealed to me.   In  
general, it would be very helpful if you could answer the questions  
that are asked when they're asked even if they reveal the fact that  
I'm a doddering old man and can't remember things from moment to  
moment,  Otherwise it's difficult (and honestly a bit frustrating) to  
try to help you.

In any case, typically the problem with frames only reveals itself  
when the entire frameset is loaded or the body of one frame causes  
the other frames to load.  Your javascript may not be helping here...  
it could be hurting.  For example, if a user reloads the "main" frame  
(say as a result of a POST request) and by doing so, during its re- 
rendering, it causes two other frames to refresh themselves due to an  
inline script function in the body of the main frame, that's the  
moral equivalent of reloading the frameset entirely.  You have a tiny  
bit more control, e.g. maybe you could set a Javscript timer to  
reload the other frames in a "staggered" way where you reload one,  
then the other after a certain number of seconds.  But otherwise it's  
the same problem.  Hard to know what's going on there.

>   Still, your point about
> the multiple threads due to the requests from individual frames when a
> frameset gets rendered is a valid one and one I have not given the  
> weight
> it deserves.
>
> Issues around multiple threads and concurrency is going to be more and
> more of a problem as we move to smarter clients and AJAX-like
> implementations.

"Smart clients" perhaps.  But Ajax is supposed to allow you to do  
interesting things *without* reloading the page, and because (to my  
knowledge) no current Javascript implementation can make a request  
asynchronously, so you can only make one request at a time from  
within a given browser document.  So using Ajax shouldn't cause  
*more* conflicts; it should cause fewer.  Unless of course your Ajax  
calls emanate from different frames (different DOM "documents").   
Then you're back in the same boat (depending on the Javascript  
implementation, I suppose).  It's really a problem with frames (or  
more generally, multiple documents at the same time) rather than with  
Ajax.

> It looks like there are several small things I can do to improve the
> present system's conflict rate, but, absent some major structural  
> changes,
> I won't be able to drive them to O(zero).  Fortunately, while the  
> level of
> conflicts is high, they are infrequent relative to the number of hits
> served, and most are resolved by the normal Zope conflict resolution
> mechanism.

Well, that's good.  Does that mean I'm off the hook? ;-)

- C