Re: [MindIO-devel] remote connection

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

At 05:49 PM 12/27/2003 -0700, you wrote:
>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.

Ok


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

OK, but should we have a go at defining such a minimal function. A separate 
thread perhaps?

>>>>>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 hadn't even considered who initiated a connection of how. There is so 
much ging on in the openEEG list right now regards this topic, i think we 
need to go with that. It is TCP based anyway, so anything is possible. The 
web-app seems to me to have the greatest potential as an off line store and 
forward methodology for the passing of session data and designs when the 
session is not real-time supervised. Originally i thought of using email 
for this, but a web-app might offer advantages.


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

Yes, it has to important or else the supervisor will make incorrect 
decisions because is not seeing the same picture


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

hmmm.. I suppose your saw my post on this. I have seen nothing since so 
expect they are considering this. mind you my email server is down atm, so 
there may be some replies. Duplex is the word we need, and function we 
need. Synchronization is always a difficult issue, since potentially both 
ends could be making changes at the same time. I have seen this  before 
with databases and is the same conceptual problem I think. Its both doable 
and essential imo.