{"push_id":682247492,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"b627bf3e0610c6813437f3eb2007e15fb6025fd2","before":"38f5258a508a83d82f2cb309d879aab0d8dcadac","commits":[{"sha":"b627bf3e0610c6813437f3eb2007e15fb6025fd2","author":{"email":"9f41a95cba557b2894771eed96e07a4ded82537f@tidoust.net","name":"François Daoust"},"message":"Continuing implementation of Socket timing provider\n\nThe code does not have any clock synchronization logic so far, so still\npretty useless. However, the basic query/update/retrieve info plumbing\nis in place.\n\nThe socket server maintains the list of online timing objects in memory\nso note that killing the server kills the objects. There are no recovery\nmechanisms in place in case of socket failure either.\n\nThe implementation triggers a number of questions:\n- what should happen when \"update\" is called on a timing object that is not\nready? Exception? Fail silently (reject potential promise returned by update\nmethod if there is one). Fall back to local behavior (would be a pain with\ncurrent implementation)\n- what ready state changes should a timing object undergo when srcObject is\nupdated?\n- what is the expectation with respect to \"timeupdate\" events? That they get\nfired at the same time across devices? How useful are such events?\n\nThe commit fixes various bugs on the Timing Object implementation as well.\n\nTo run the short and simple example, run the following commands in different\ncommand-line tabs to start the server, start code that merely listens to\n\"timeupdate\" events on an online timing object and start code that updates\nand listens to the same timing object:\n\nnode examples/server.js\nnode examples/sockettiminglistener.js\nnode examples/sockettiming.js","distinct":true,"url":"https://api.github.com/repos/tidoust/timingservice/commits/b627bf3e0610c6813437f3eb2007e15fb6025fd2"}]}