{"action":"created","issue":{"url":"https://api.github.com/repos/JMRI/JMRI/issues/1834","repository_url":"https://api.github.com/repos/JMRI/JMRI","labels_url":"https://api.github.com/repos/JMRI/JMRI/issues/1834/labels{/name}","comments_url":"https://api.github.com/repos/JMRI/JMRI/issues/1834/comments","events_url":"https://api.github.com/repos/JMRI/JMRI/issues/1834/events","html_url":"https://github.com/JMRI/JMRI/issues/1834","id":172053389,"number":1834,"title":"Potential issue with IDTag and RailCom objects.","user":{"login":"pabender","id":14183416,"avatar_url":"https://avatars.githubusercontent.com/u/14183416?v=3","gravatar_id":"","url":"https://api.github.com/users/pabender","html_url":"https://github.com/pabender","followers_url":"https://api.github.com/users/pabender/followers","following_url":"https://api.github.com/users/pabender/following{/other_user}","gists_url":"https://api.github.com/users/pabender/gists{/gist_id}","starred_url":"https://api.github.com/users/pabender/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pabender/subscriptions","organizations_url":"https://api.github.com/users/pabender/orgs","repos_url":"https://api.github.com/users/pabender/repos","events_url":"https://api.github.com/users/pabender/events{/privacy}","received_events_url":"https://api.github.com/users/pabender/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/JMRI/JMRI/labels/enhancement","name":"enhancement","color":"30C030"},{"url":"https://api.github.com/repos/JMRI/JMRI/labels/infrastructure","name":"infrastructure","color":"fef2c0"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-08-19T04:42:41Z","updated_at":"2016-08-29T18:58:12Z","closed_at":null,"body":"While working on support for RailCom on Roco Z21 systems, I discovered a potential problem that needs to be investigated.\r\n\r\nThe issue comes about because we have IdTag objects and RailCom objects (jmri.RailCom extends jmri.IdTag).\r\n\r\nIdTag objects are provided by the default IdTagManager.\r\n\r\nRailcom objects are provided by the default RailComManager, but they don't appear to ever be registered with the IdTag manager.  (There is currently only one system (Dcc4Pc) actually registering RailCom objects, but that really should change.  There are at least 3 other systems that support RailCom, and we eventually need to also ).\r\n\r\nThe potential issue we have is that when we are trying to identify things by IdTag, we're not currently going to see anything that is registered as a RailCom object, but we should.\r\n\r\nWe also need to look at how RailCom objects are stored and restored.  They really should be written to the same file as the IdTags, so the Ids are not duplicated between the two managers.\r\n\r\nThere is a further potential issue down the road, if we ever move LocoNet reporters off of producing strings as the reports, because transponding messages are also identifiable objects.\r\n\r\n(The long term vision for this issue is that some day we will have a user who wants to mix identification systems.  The Locomotives already have decoders in them, so if they can identify themselves on the rails, then that solves the identification problem for them.  Rolling stock usually doesn't have a decoder, so you have to add something to it before it can identify itself, and RFID and barcodes are cheap....  but of course the decoders are able to provide more information than the barcodes and RFID tags do...)"},"comment":{"url":"https://api.github.com/repos/JMRI/JMRI/issues/comments/243220417","html_url":"https://github.com/JMRI/JMRI/issues/1834#issuecomment-243220417","issue_url":"https://api.github.com/repos/JMRI/JMRI/issues/1834","id":243220417,"user":{"login":"rhwood","id":297232,"avatar_url":"https://avatars.githubusercontent.com/u/297232?v=3","gravatar_id":"","url":"https://api.github.com/users/rhwood","html_url":"https://github.com/rhwood","followers_url":"https://api.github.com/users/rhwood/followers","following_url":"https://api.github.com/users/rhwood/following{/other_user}","gists_url":"https://api.github.com/users/rhwood/gists{/gist_id}","starred_url":"https://api.github.com/users/rhwood/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rhwood/subscriptions","organizations_url":"https://api.github.com/users/rhwood/orgs","repos_url":"https://api.github.com/users/rhwood/repos","events_url":"https://api.github.com/users/rhwood/events{/privacy}","received_events_url":"https://api.github.com/users/rhwood/received_events","type":"User","site_admin":false},"created_at":"2016-08-29T18:58:12Z","updated_at":"2016-08-29T18:58:12Z","body":"This is the first code change that shops with JMRI that has been labeled as infrastructure. If the meaning is going to change to indicate JMRI intervals that should not (but given past experience will) be user visible, how should we now label project infrastructure issues to be distinguishable from issues with the JMRI programs?\n\nRandall Wood\nAlexandria Software\nrandall.h.wood@alexandriasoftware.com\nhttp://alexandriasoftware.com\n\n> On Aug 29, 2016, at 14:31, Paul Bender <notifications@github.com> wrote:\n> \n> I've been using infrastructure to indicate code changes that should not be visible to users also. Mostly this has applied to test related items, but it fits here as well.\n> \n> —\n> You are receiving this because you commented.\n> Reply to this email directly, view it on GitHub, or mute the thread.\n> \n"}}
{"actor":{"display_login":"rhwood"}}