{"action":"created","issue":{"url":"https://api.github.com/repos/openstf/stf/issues/101","labels_url":"https://api.github.com/repos/openstf/stf/issues/101/labels{/name}","comments_url":"https://api.github.com/repos/openstf/stf/issues/101/comments","events_url":"https://api.github.com/repos/openstf/stf/issues/101/events","html_url":"https://github.com/openstf/stf/pull/101","id":110202486,"number":101,"title":"Device Booking feature","user":{"login":"hogehoge-banana","id":2498574,"avatar_url":"https://avatars.githubusercontent.com/u/2498574?v=3","gravatar_id":"","url":"https://api.github.com/users/hogehoge-banana","html_url":"https://github.com/hogehoge-banana","followers_url":"https://api.github.com/users/hogehoge-banana/followers","following_url":"https://api.github.com/users/hogehoge-banana/following{/other_user}","gists_url":"https://api.github.com/users/hogehoge-banana/gists{/gist_id}","starred_url":"https://api.github.com/users/hogehoge-banana/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hogehoge-banana/subscriptions","organizations_url":"https://api.github.com/users/hogehoge-banana/orgs","repos_url":"https://api.github.com/users/hogehoge-banana/repos","events_url":"https://api.github.com/users/hogehoge-banana/events{/privacy}","received_events_url":"https://api.github.com/users/hogehoge-banana/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2015-10-07T11:15:12Z","updated_at":"2015-11-23T18:18:07Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/openstf/stf/pulls/101","html_url":"https://github.com/openstf/stf/pull/101","diff_url":"https://github.com/openstf/stf/pull/101.diff","patch_url":"https://github.com/openstf/stf/pull/101.patch"},"body":"# Overview\r\n\r\nThis is Device booking feature. You can book device schedule on device-list. then, device scheduler unit  set you to \"owner\" on the time. And reject other user if the device is busy. device scheduler will check device schedule per a minute.\r\n\r\n# Note\r\n\r\nYou can book schedule from one hour later.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/openstf/stf/issues/comments/159017350","html_url":"https://github.com/openstf/stf/pull/101#issuecomment-159017350","issue_url":"https://api.github.com/repos/openstf/stf/issues/101","id":159017350,"user":{"login":"sorccu","id":32509,"avatar_url":"https://avatars.githubusercontent.com/u/32509?v=3","gravatar_id":"","url":"https://api.github.com/users/sorccu","html_url":"https://github.com/sorccu","followers_url":"https://api.github.com/users/sorccu/followers","following_url":"https://api.github.com/users/sorccu/following{/other_user}","gists_url":"https://api.github.com/users/sorccu/gists{/gist_id}","starred_url":"https://api.github.com/users/sorccu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sorccu/subscriptions","organizations_url":"https://api.github.com/users/sorccu/orgs","repos_url":"https://api.github.com/users/sorccu/repos","events_url":"https://api.github.com/users/sorccu/events{/privacy}","received_events_url":"https://api.github.com/users/sorccu/received_events","type":"User","site_admin":false},"created_at":"2015-11-23T18:18:07Z","updated_at":"2015-11-23T18:18:07Z","body":"I think I would do something like this instead of polling every minute. It's not necessarily the best way though. Also, make sure to read all the way to the end.\r\n\r\n1. Add `lib/units/device/plugins/reserve.js`\r\n2. In there, start listening for a `ReserveUpdateMessage`, and send a `ReserveUpdateRequestMessage` when the device worker loads (just a sample name)\r\n3. `processor` receives it, loads the full schedule for that device from the database, and a `ReserveUpdateMessage` back to the device with the details\r\n4. The device worker wait for the nearest reservation, if any.\r\n    - By either setting a timeout for the nearest job - 10s, and then kicking out whoever is using the device (if anyone) and make the scheduled user the owner, `setTimeout()` isn't super accurate so it should trigger a bit earlier (and it won't do much harm)\r\n    - OR perhaps instead of `setTimeout`, always have a `setInterval` running in the background in the device process (perhaps checked once per minute). When the callback triggers, check the internal state if the next reservation is closer than the next internal. If so, kick out current user and make the scheduled user the owner.\r\n5. If a new reservation is made, send a new `ReserveUpdateMessage` with the full schedule to the device channel\r\n    - Update internal in-memory state\r\n    - Clear `setTimeout` or `setInterval`, run a check immediately, and set up new timers\r\n\r\nStep 5 could be made easier if we handled messages from the application side in the processor. That way you could just send a tiny message to the processor and it would load and send a full `ReserveUpdateMessage` to the device channel. However since it's not possible right now, what you'd probably have to do is to create the full `ReserveUpdateMessage` in the `websocket` or `app` unit, and then send it as-is to the processor.\r\n\r\nHOWEVER, I like having the reservation functionality completely separate from the device process like it is in your patch (reaper style). It makes it easier to manage. It would be best if you could adapt the steps in your `scheduler` unit instead. You could then even use RethinkDB's `.watch()` in the `scheduler` unit to load schedule changes in real time, and send `ReserveUpdateMessage` to appropriate devices when necessary. That you you wouldn't necessarily have to send a separate message from the `websocket` or `app` unit to the `scheduler` unit, it would automatically see all changes."}}