[Pipet Devel] Idl

[Brad Chapman]

Jarl wrote:
> I've been adding some to the idl brad created,
> i'll work more on it tonight\tomorrow, but this is what I came up 
with.

Thanks for looking at this.In general I'd like to try and make the 
interface smaller (since I'm lazy and want to implement as few 
interfaces and functions as possible :) 
    Also, the uri_t you are referring to (as a reference to a node or 
subnet) is the same thing I was referring to using two references, a 
process_id and a node_id. Maybe we could combine the two ideas by 
having the uri_t be a string concatenation of the two separated by a 
color (ie. uri_t = 'process_id:node_id').

Here are my specific thoughts (a lot of this is just talking out loud, 
so please bare with me!):

For the SUBNET interface:

    These are for accessing whole subnets or programs (so GMS type 
nodes) after they have been sent a workflow/xml_structure to process 
(ie. a whole bunch of connected nodes), right? 
    My question is, do we really need this level of control so that 
someone can
manipulate a process so much while it is running? The way I was 
thinking of the GUI and processing engine working together are that 
the user spends some time getting a nice process of connected nodes 
set up, and then hits run and waits for the output to come out at the 
specific nodes/subnets they are interested in. If this is the case, 
then why and when would they need to access a process to remove, 
activate, destruct, add, etc. nodes and subnets?
    Am I being naive here in thinking that we don't need all of this 
control of a running process? Perhaps what we do need though it a 
method for cancelling and run and getting as much information as you 
can from it...

    So can we drop these following functions out and leave it up to 
the processor to get this information from the xml that is sent?
 
uri_t new(in string dname, in string ddescription, in string 
datadescription, in string allowedfilter);
boolean destruct(in uri_t uri);
boolean init(in uri_t uri);
boolean activate(in uri_t uri);
uri_t duplicate(in uri_t uri);
    
    boolean SETdname(in uri_t uri, in string displayedname);

    boolean SETallowedFilter(in uri_t uri, in string allowedfilter);
    boolean SETconfiguration(in uri_t uri, in string configruntime);
			  boolean SETdataDescription(in uri_t uri, in string 
datadescription);
    string GETdataDescription(in uri_t uri);
    string GETdname(in uri_t uri);

For the following functions--do we need the processor to know about 
the description of the program? Can all of this type of information by 
stored in xml in the "middle scripting thingy"?

    boolean SETdDescription(in uri_t uri, in string 
displayeddescription);

    string GETdDescription(in uri_t uri);

For the following functions: I don't really understand the set status 
(how does the scripting engine set the status of a process?). I tried 
to include GETstatus type stuff in my query_process function. But 
maybe we should split this querying to be specific for a subnet or 
node?

    boolean SETstatus(in uri_t uri, in status_t status);
    status_t GETstatus(in uri_t uri);

For the following, I'm not really positive why the middle would need 
to know this stuff? Do you want the GUI to restrict only allowed 
things to be connected? This seems *really* hard to maintain--maybe it 
would be better to have the processing engine generate errors and then 
propogate them back to the GUI so the user can fix them? The idl 
probably does need a better way to return back error messages.

    string GETallowedFilter(in uri_t uri);
    string GETconfiguration(in uri_t uri);

For the following, do we still need the processing engine to store a 
log/history of events, or should this be handled by the middle 
scripting part, which can maintain logs for all its communication. 

    MDO_t GEThistoricdata(in uri_t uri, in long history);


For the NODE interface:
    I think the same kind of comments I made above apply here: how 
about if we just send all of this information to the middle as XML. I 
think that the current Overflow XML will be a good point to start with 
and we can work from there. What I need to get working is a way to 
turn the directory/heirarchy based file storage system that Loci 
currently has into the type of flat XML that Overflow uses, so I can 
pass this. While the heirarchial structure is best for dealing with 
the GUI (since I have to make lots of changes to it as the GUI 
changes, it is easier to break it up into smaller chunks for 
manageability and speed), the flat file format is what we need so that 
we can pass a single file to the processing engine to process (and to 
stay compatible with what Overflow does since they have a good thing 
going). We also will not want to pass all of the info that is stored 
in XML in the middle (like descriptions of programs, etc.) to the 
processing engine, so some kind of transformation will be needed. I 
need to start trying to think about how to do this, but I hope it 
shouldn't be too bad...
    Thanks again for checking out the idl, Jarl. Hopefully all of us 
can get it hashed out over the next few days without a problem.

Brad