Re: [MindIO-devel] ApplicationObject

[Ian V. <vi...@ig...>]

At 07:33 PM 12/23/2003 -0700, you wrote:
>Ian Vincent wrote:
>
>>Jeremy- I am way out of my depth here, and never expected to be doing 
>>this stuff, but it is fun. I am taking all of these ideas from the 
>>graphic of the CorelDraw object set that sits on the side of my PC, but I 
>>have also seen this application centered design principle used in other 
>>object sets like Excel, and Clarion, so I know it is sound from an 
>>engineering pov. It makes good sense to have a master 'Application 
>>object', don't you think.
>
>
>Actually, I think we should design the 'engine' to be independent of any 
>particular application.  I have a couple reasons for this.  One reason is 
>that objects that fit into this API could be used in various types of 
>biofeedback applications, developed by various types of people.  That will 
>make it easier for other people to develop biofeedback software, since 
>they can use objects that are already written, and it will be beneficial 
>for us because we might be able to use objects written by other 
>people.  The other reason relates to the so-called "Software Development 
>Problem".  A complete neurofeedback application like you speak of is a 
>large undertaking, and I think that we should try to avoid a problem most 
>software projects have, which is that they are totally useless until 
>they're complete.  We don't know what the future may bring.  Perhaps this 
>won't be completed by us.

I personally am putting in the time and effort on this project so that we 
can get the job done. I don't have any  'not completed' in my plans since 
it simply has be done, whatever it takes. To me that would be like saying 
that we don't actually need it. but I do get your point. I think that is 
the fate of the partly completed OpenEEG library project that has already 
passed into the land of 'not completed'. Interesting point though. I guess 
if we look toward each seperate object as having its own completion, ie it 
does its job and functions in its own right. Objects are tools, and do a 
specific job but can relatively useless on their own. This is why I see 
tying our objects together under the umbrella of an application object does 
give them a coherent structural framework in which they become a 
functioning whole.

I don't know if you are familiar with Tony Buzan's MindMapping concepts, 
but they always rely on a central object from which all other attached 
concepts relate, so this appears to me to be totally compatible with 
'application object' . These days my entire thinking toward systems design 
uses this principle.


>  But if we have a refined and well-designed API, and complete objects, it 
> would be easier for someone else to write a few more objects and tie it 
> all together into an application.  I think the reason nobody is working 
> on EEGMIR is that they would need to totally understand the inner 
> workings of the present code.  But it will possible for someone to use 
> our objects without understanding their inner workings.

Yes..this appears to be be the very advantage of object oriented design, in 
that the objects can actually be used generically. ie they are what where 
originally termed 'black boxes'.


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

Ian