Newbie question communicating between 2 progs

[Don Garrett]

Ben Thursfield wrote:
> 
> Peter Hansen schrieb:
> 
> 
>>The question is ambiguous.  When you say "frames", the only thing
>>that comes to mind is that you are running Python on client-side
>>Internet Explorer under Windows, as scripts in two different parts
>>of a window (the frames) simultaneously.  I think you must have
>>meant something different however.
>>
>>Could you please describe more about your environment?  The
>>term "frame" can mean a number of things.
> 
> 
> That's right. I am running 2 cgi-scripts in two different frames of the
> browser, the one should only print an array into the frame and the other one
> communicates with a server. I decided to split the programm up because i want
> to refresh the printing frame every second. The main frame changes the array
> the second frame prints it out. My host has Python installed, so the
> #usr/bin/python method works fine.
> So the question is how can the programm responsible for printing out the array
> access the array defined in the other programm.

   This is a suprisingly hard problem.

   The two programs are only running while the frame they handle is being 
generated. They shutdown and start up on each refresh request. I'm assuming 
you aren't using some form of server push, which has it's own problems. They 
don't save any state at all between refreshes of the same page. This means you 
have to solve the problem of having a program communicate it's state to 
itself! The good news is that when the program can communicate to itself, you 
can use the same mechanism to communicate with the other frame.

   However, the best answer to your question is to use cookies. The contents 
should be visible to all pages on the local site (you can control this) so 
they will allow you scripts to communicate with themselves and each other. You 
can store a fair amount in one (I'm not sure what the size limit is), and it 
can be binary.

   A few warnings.

   Some people disable cookies. This can totally break your site.

   All cookies are always uploaded as part of every page request everywhere 
they are visible. This means that you shouldn't make them too large or you 
will slow your site. If they are big, try to restrict cookie visibility to 
just the pages that really need them. You can specify where the cookies are 
visible when you create them. You can even store the state info in a database 
and use the cookie as a key to retreive it.

   When it comes to security, you cannot trust the contents of the cookie. The 
contents need to be validated the same way the values from a form would be. A 
tricky black hat can force the cookie contents to be anything they want.

   Two last bits of advice from an old web developer (well as old as a web 
developer can be).

   Try to avoid frames. They cause a lot of problems for both you and for your 
users. For example, they often break cross-browser, they can break bookmarks, 
and they can break printing.

   Try to avoid refreshes, especially frequent ones. Someone with a poor link 
will spend more time looking at an empty page that hasn't loaded than they 
will looking at your content.

> I hope i described the problem better now.
> 
> Ben
> 

-- 
Don Garrett                             http://www.bgb.cc/garrett/
BGB Consulting                                      garrett at bgb.cc