Re: [MindIO-devel] remote connection

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

Ian Vincent wrote:

> I just presume that the connection would be handled by a specialist 
> terminal object and is conceptually similar to the ones that would 
> handle data streaming to file. Effectively the 'connection' is to an 
> external device, just as with audio, file, etc. Basically these 
> Terminal objects are identifiable by the fact that they have Rx's and 
> no Tx's. 'End of the line' Terminals, rather than 'pass through' 
> Terminals. Something like that. 

You're right, my mistake.  They would be 'end of the line', not 'pass 
through'.  There is no need for 'pass through' Terminals, because a Tx 
can output to more than one Rx.

> Yes, this is also my thinking, that MindIO will be minimalist in terms 
> of clinical NFB function but will contain objects that can be used 
> elsewhere. It could be a single 'segment' application, much like BE 
> currently is. 

Perhaps we can start out with minimal function and plan to expand it 
over time.


>
>
>
>>>> If the supervisor needed the ability to modify the  layout at 
>>>> run-time, that
>>>> could be built into the application and would also not require any 
>>>> change to
>>>> our general object relationship design.
>>>
>>>
>>> Since we need the Trainee to be able to train when the supervisor is 
>>> off line, 24/7 there is a case for there being a supervisor server 
>>> of some kind where the Trainee can log into to download session 
>>> designs etc perhaps. Maybe this server could act as a go between for 
>>> all Trainee/Supervisor transfers. One factor that I haven't even 
>>> mentioned is that the Trainee needs to be able to assess the effect 
>>> of each segment and transfer that info to the supervisor. This would 
>>> ideally be in the form of a brief questionaire, and a html server 
>>> could work well in this role. Its getting complicated though. Part 
>>> of Trainee training is the doing of this self assessment, and is an 
>>> integral part of the self training concept. The results of the 
>>> assessment are used in customising the following sessions.
>>
>>
>> I think you're talking about a server-side web application.  You 
>> could say that's my specialty, as that's the majority of programming 
>> that I've done recently.  That's how I make a living (one of my three 
>> jobs, anyway).
>
>
> Take for instance the situation where the supervisor had two or more 
> trainees training concurrently, or where the supervisor was of lnie or 
> doing something else, like sleeping. A server side web app could 
> manange the training process, including the collection and storage of 
> session EEG data for retrieval by the supervisor as and when required. 
> It could also manage the transmission of session and layout designs as 
> required. I actually really like this conception.
>
> Jeremy..read through this scenario and take a stab at the question at 
> the end. Assume for this example, that we are using a server side app 
> rather than a socket connection. The Terminal object transmits EEG 
> data to the server side app, via http, the server processes this data, 
> stores it in its data base, and if required echos it to the 
> supervisor. What would the time delay be reasonably expected to be. I 
> realise that there are variables in here such as the number of 
> concurrent trainees, the server cpu speed, the server loading, the 
> nature of the app, or whatever. Can you give a ball park. Could it 
> typically be within say 3 seconds. Why I ask is that there is no 
> absolute need for strict real time monitoring in this situation, and a 
> few seconds delay is acceptable. 

If it's implemented as a web-app, then all the server can do is respond 
to requests by the client.  I'm not sure what you're asking with the 
delay.  I think 3 seconds is doable, but if the supervisor might want to 
change settings, there might need to be a way for the supervisor to 
initiate a connection at any time, which isn't feasible with a web-app, IMO.


> I just thought of a new connectivity issue and that is that the 
> supervisor should somehow know exactly what the Trainee is 'actually' 
> seeing and hearing so some mechanism needs to be in place to correlate 
> the two systems. Trainees can change Terminal properties at run time 
> and the reward response of the system will reflect that, so somehow 
> these changes need to get through to the supervisor. Reward ratios are 
> an important factor and Trainees might get them wrong initially, so 
> the supervisor needs to be able to monitor that. Seems we almost need 
> some kind of ongoing change log or something. This is very important 
> and have not previously thought of it. More thinking needed here. 

Okay, then we need a way to synchronize the layout between the 
supervisor's and trainee's computers, so they'll see the same results if 
they both process the same data.

I think Rudi's suggestion of an OpenEEG Server is really good, but maybe 
it could somehow allow two-way communication between clients.  It would 
need to be general and not specific to a particular application, though, 
so maybe it isn't feasible.

Jeremy