{"action":"created","issue":{"url":"https://api.github.com/repos/IGSIO/OpenIGTLinkIF/issues/6","labels_url":"https://api.github.com/repos/IGSIO/OpenIGTLinkIF/issues/6/labels{/name}","comments_url":"https://api.github.com/repos/IGSIO/OpenIGTLinkIF/issues/6/comments","events_url":"https://api.github.com/repos/IGSIO/OpenIGTLinkIF/issues/6/events","html_url":"https://github.com/IGSIO/OpenIGTLinkIF/issues/6","id":127306239,"number":6,"title":"Standalone igtl Client","user":{"login":"christiana","id":436646,"avatar_url":"https://avatars.githubusercontent.com/u/436646?v=3","gravatar_id":"","url":"https://api.github.com/users/christiana","html_url":"https://github.com/christiana","followers_url":"https://api.github.com/users/christiana/followers","following_url":"https://api.github.com/users/christiana/following{/other_user}","gists_url":"https://api.github.com/users/christiana/gists{/gist_id}","starred_url":"https://api.github.com/users/christiana/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/christiana/subscriptions","organizations_url":"https://api.github.com/users/christiana/orgs","repos_url":"https://api.github.com/users/christiana/repos","events_url":"https://api.github.com/users/christiana/events{/privacy}","received_events_url":"https://api.github.com/users/christiana/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":19,"created_at":"2016-01-18T20:35:45Z","updated_at":"2016-01-27T22:22:44Z","closed_at":null,"body":"I have been considering how to extract a full standalone igtl Client from the OpenIGTLinkIF repo, as discussed in Boston (http://wiki.na-mic.org/Wiki/index.php/2016_Winter_Project_Week/Projects/TrackedUltrasoundStandardization).\r\n\r\nFor testing and possibly for use in applications, we would like the GUI from OpenIGTLink as Slicer-independent code. There should also be possible to reuse more basic parts of the library, either the full Client (no GUI), or only the converter classes. Suggested dependencies below:\r\n![igtlclient_uml](https://cloud.githubusercontent.com/assets/436646/12401708/826b9464-be28-11e5-8d38-50bc69b61c35.png)\r\n\r\nAll the Slicer-independent code could ultimately be included in the OpenIGTLink repo itself, every module as a conditional build.\r\n\r\nThe Client itself can be separated from Slicer like shown in the diagram:\r\n![igtlclient_uml](https://cloud.githubusercontent.com/assets/436646/12401999/617b102a-be2a-11e5-9527-72192a4d9fcd.png)\r\n\r\nThe main idea is to remove the inheritance from MRMLNode ( currently Connector, Converterts and Devices all are MRMLNodes), and instead use aggregation, i.e. Slicer will listen to the Client and create MRMLNodes wrapping the igtl devices/connectors as needed. The Converters could be an implementation detail hidden from external users. The Manager would contain much of the code currently present in vtkSlicerOpenIGTLinkIFLogic. A data layer duplicating some of MRML's features would have to be implemented (i.e. the Nodes), but this can be made as simple as possible, with no persistence (for now).\r\n\r\nI am very interested in comments to this proposal, in particular: \r\n* Do this (first) design outlined look sound, what can be improved?\r\n* Who is interested in the resulting code, and at what level?\r\n* Can the result eventually be merged back into Slicer? This determines whether or not we should refactor the Slicer binding layer or simply extract the code of interest.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/IGSIO/OpenIGTLinkIF/issues/comments/175891264","html_url":"https://github.com/IGSIO/OpenIGTLinkIF/issues/6#issuecomment-175891264","issue_url":"https://api.github.com/repos/IGSIO/OpenIGTLinkIF/issues/6","id":175891264,"user":{"login":"christiana","id":436646,"avatar_url":"https://avatars.githubusercontent.com/u/436646?v=3","gravatar_id":"","url":"https://api.github.com/users/christiana","html_url":"https://github.com/christiana","followers_url":"https://api.github.com/users/christiana/followers","following_url":"https://api.github.com/users/christiana/following{/other_user}","gists_url":"https://api.github.com/users/christiana/gists{/gist_id}","starred_url":"https://api.github.com/users/christiana/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/christiana/subscriptions","organizations_url":"https://api.github.com/users/christiana/orgs","repos_url":"https://api.github.com/users/christiana/repos","events_url":"https://api.github.com/users/christiana/events{/privacy}","received_events_url":"https://api.github.com/users/christiana/received_events","type":"User","site_admin":false},"created_at":"2016-01-27T22:22:44Z","updated_at":"2016-01-27T22:22:44Z","body":"The first step is now available on https://github.com/christiana/OpenIGTLinkIO. The working code now consist of the folders Converters, Logic, Devices, just check the root CMakeLists.txt to see what's in use. The other files are not in use and will be upgraded or removed in the next step.\r\n\r\nThe structure is now pretty much like in the last diagram in this thread, with vtkIGTLIOLogic as the manager of a set of Connections, each with a list of Devices. igtl message conversion is done by the Devices themselves. Each of the new classes have a short description in-code.\r\n\r\nMain changes from the old OpenIGTLinkIF code:\r\n- Independent of Slicer, only depends on igtl and vtk.\r\n- removal of MRML gave a simpler data structure - much of the complexity in OpenIGTLinkIF lies in the interaction with MRML and a lack of an interface layer between the two.\r\n- Only support for ImageDevice yet.\r\n- Query mechanism (GET_, STT_, ...) was in a MRML node, now moved into the Device superclass. I could not find any users of this code, does anyone know a project where it is used?\r\n- Creation of Devices are now in a Factory object.\r\n\r\nThe code compiles, but have not been tested at all, thus you should only look at the structure and not the details. Next steps are adding a standalone gui, then reconnecting to Slicer. Slicer reconnection would be the hardest step, but should give a slimmer OpenIGTLinkIF.\r\n\r\nComments are welcome. \r\n\r\nMostly anything can be changed at this point, including repo organization. It might be easiest to migrate the end result into optional folders of OpenIGTLink itself, instead of having a separate repo."}}