[Pipet Devel] J.W. Bizzaro; TODO 20000218

[Brad Chapman]

> I was thinking about the event handlers being in their own modules.  
But, do
> you think splitting up such highly accessed methods (e.g., whenever 
a locus
> gets dragged) will slow things down?  This is a question I have 
about Python
> operation.  Maybe someone here knows the answer to that.

Not me! I don't really know the internal methods by which 
interclass communication occurs, but I guess I've never read anything 
about splitting things into classes making them slower, so I would 
agree that it's a good idea to try.

>> Let me know if the stuff I did makes sense when you start looking 
at this.
>> I might be able to make it cleaner/more usable if there are 
problems.
> 
> I was planning on making a method that is the inverse of the 
connect_loci
> method.  I'll go check out what you did.

That's pretty much what I tried to do. I just stared at connect_loci 
for a long while and then tried to reverse all of the changes it made.

> Can we put a blank database container in one of the main
> containers/directories?
> 
>    $LOCIHOME/back/private/container/
> 
> Blank containers are wrappers with an XML description (like all 
loci),
> right? 

Right--I think this shouldn't be a big problem. I need to start 
thinking more about how to create permanent storage of xml to it can 
reopened.

> As for keeping 'permanent' loci 'out of the way', How about having a 
'hide
> locus' option that makes a locus invisible although not deleted?

This is a neat idea, but might be hard to keep track of, both 
programmatically and the user. I know that if my icons could be made 
invisible I would forget about half of them and end up with all kinds 
of "invisible" junk that is just taking up space. But maybe that's 
just me...
  
> What may be confusing, and I'm not sure how much I wrote about this 
to you,
> is
> that the front-end(s) and the middleware will communicate by sending 
XML tags
> back and forth.  And the tags are commands.  Here's an example:
> 
>    <gi locus_select id=387hwj7843>        gi requests selection of 
locus
>    <middle locus_select id=387hwj7843>    middle approves

I remember something about this from before, but I'm not positive that 
I completely get it. Which events on a workspace will generate this 
kind of xml dialog? 
    Everything? (ie. selects, moves, etc...) It seems to me that 
things like this would be better left to the front end and just leave 
the middle to deal more with issues that involve more "permanent" 
changes (like connections). I am just worried that a lot of talking 
between front and middle might slow things down, but then again, what 
do I know about speed issues?
    Also, I wonder why we need this kind of dialog--why can't we just 
talk back and forth in python? It seems like even with a web 
interface, you'll have to have some kind of language generating the 
tags and recieving the responses, and why not make that python?

> allows us to do that.  Heck, we can even 'play back' the entire work 
session,
> with the workspace reenacting for the user what was done.  Cooooool.

The idea is *really* cool, but I just worry about the implementation 
time for an xml communciation pathway like this. Wouldn't this be a 
lot of work?
 
> Gary and I developed this approach together.  If you have more 
questions,
> perhaps Gary can join in on the conversion ;-)

It seems like with all of the separation between middleware and 
frontendware beginning to become clearer in my mind it might make 
sense for me to focus more on middleware work (which needs *a lot* of 
work), especially since your ToDo stuff is focused on frontend stuff. 
This is a fine arrangement for me--who needs to look at pretty 
pictures while they're programming? Certainly not me :-)

Brad