Hi Matt, that's great! Thanks for your participation.
Regarding your considerations: a) I think it is necessary that MITK has the ability to function as a client and a server. Imagine you want to connect to another software that just functions as a server, then MITK has to be the client. And if you want to offer data to another software or another MITK instance, MITK has to function as the server. This can be useful to overcome a platform dependency, e.g. running the hardware from a Windows PC which streams the data to a Linux machine. b) My idea was to register the OpenIGTLink source as a microservice similar to NavigationDataSource. c) For the beginning it is not planned to publish it on the CTK event bus. But in the future that could be useful. We will discuss this. d) We will take the queuing into account. But I am not sure on which layer it shall be done. e) I agree with you, it is kind of odd... *f) Are you already using OpenIGTLink? I am currently working on a concept paper. Once it is finished I will send it to you. Best regards, Martin On 10.10.2014 09:40, Clarkson, Matt wrote: > Hi there, > > we would use it. > > I would also like to participate in the design and implementation of such a > feature. > > As the type of messages is application specific, and the message protocol > itself can be expanded over time, I would have thought that initial > considerations should include: > a) Does an MITK GUI app such as MITK workbench function as a client or > server? > b) Which layer to implement this in … eg. starting and stopping a > microservice. > c) What to do with incoming messages? eg. publish on CTK event bus? Then > ANY plugin can listen. > d) Are messages queued and you process all of them, or do you just process > them in your own thread, and miss intermediate messages if you are busy. > e) Make sure we all understand the timestamp format, as I initially found > it a little odd … but it does make sense after a while…. (or maybe I needed > more coffee at the time of reading). > > Matt > > > On 9 Oct 2014, at 15:19, MartinKlemm <[email protected]> wrote: > >> Hello everyone, >> >> we are thinking about integrating OpenIGTLink support into MITK. It >> would be interesting to know if you would use this and what you would >> use it for. What would be your requirements for such an implementation >> (e.g. which data shall be sent? Who communicates with whom?). >> >> Thank you for your feedback. >> >> Best regards, >> >> Martin >> >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> _______________________________________________ >> mitk-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mitk-users ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
