[Zope] More on understanding conflicts

[Dennis Allison]

On Wed, 21 Dec 2005, Chris McDonough wrote:

> 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.

Sorry if I appeared unresponsive--the fact that we use frames is hardly a 
secret.   I suppose that it would be helpful to make up soem summary of 
features for ongoing threads like this one.  

> 
> 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.

By convention the primary content frame does not cause other frames to 
re-render but there are multiple implementors and creaping featurism
which may have changed that.  The navigation_box frame we have been 
discussion gets re-rendered on a navigation change (duh) and may initiate
re-rendering of a tabs_frame.  Except for the full frameset rendering,
we are likely to be fairly conflict clean.  I can look in the logs and 
tell...  Might be interesting.


> >   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.

I did not know that XMLHttp interactions were asynchronous but serialized.  
Most browsers can make multiple simultaneous requests so I'd assumed that 
XMLHttp would just grab a connection and go and that multiple requests 
can be in progress simultaneously.

> > 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? ;-)

Not really off the hook as issues still remain and you are a valuable
resource.  :-)  I need to spend some time thinking about the issues an do
some cautious experimentation and testing.