Re: [MindIO-devel] ApplicationObject

[Jeremy W. <jjw...@ub...>]

>
>
>> I would really prefer to refine the API design a little further, then 
>> develop the basic objects, and only then work on an actual 
>> application that uses those objects.  Kind of a ground-up approach.  
>> If we set our initial goals too high, we might do a lot of work and 
>> end up with nothing to show for it.  I think this is the problem that 
>> has plagued other attempts to develop software for ModEEG.
>
>
> I agree, but by also defining a potential over all framework, ie the 
> 'applicationobject', any resulting API will reflect its needs. This 
> brings up two points:
> 1. There appears to be potentially two API's. One is internal and 
> defines the communication between the various terminal objects, (cells 
> perhaps) and the other is a potential external API that is what I 
> refer to as the automation engine approach which defines communication 
> between the mindio app and another host app, such as the supervisor 
> app that I proposed . It is potentially possible that we may end up 
> with both. I personally have no problem with the added conceptual 
> complexity of this idea, since I know from experience that engineering 
> problems are often solved by the introduction of additional layers of 
> complexity, though the corollary of this is that additional complexity 
> should only be added if no other option is viable. Another design 
> philosophy holds that sometimes the additional layers are added to 
> solve problems, but in some later evolution the layers dissolve into a 
> new approach that solves all of the problems. Such is philosophy. ;-) 
> Do you get my drift here?
>
> However I do agree that we should concentrate on defining the 
> 'internal' API at this stage. 

I am sure that when we start working on the application, or external 
API, that we will see that changes need to be made to the internal API.  
In fact, I was just thinking about writing the ModEEG object and I 
realized it would make more sense for the Tx and Rx to be classes 
instead of interfaces, as most of their functionality will be the same 
for every Terminal.  However, I believe that later changes to the 
internal API will be small and that, for various reasons, we should 
concentrate on the internal API first.