I think you can work around that. First, if there is a 300 ms delay from the server response, the timer would be off by 600 ms total and I don't think that anyone cares about half a second. The time to press the stop button is well over half a second already unless you hover over the stop button beforehand. But if you really want it to be ultra precise, you can put that 600 ms into the equation because the response also includes the time of how long the request took so you can substract that delay in your calculations and then you are as precise as you can get, maybe off by 5 ms or something.
I may be wrong with this, I haven't tried it, but I think this should work. Your other points are valid though. Although personally I don't care about having to scroll to see the timer but that's a matter of taste of course. On Feb 9, 6:59 pm, dataist <piotr.kulaga...@gmail.com> wrote: > There are obvious technical problems related to the stopwatch > synchronicity and latency on various participants' screens (pings of > over 300ms between Sydney and US are common due to switch and repeater > loads, even though light should cross the pacific over fibre in about > 6ms). Further complications arise from time zone differences and > summertime changes/updates in various regions, this leads me to > believe that a gadget isn't an ideal implementation. > > Since the Wave server keeps a chronology of all edits and the page is > readily updated (near enough to real time), perhaps a lower level > solution is more appropriate. The UI (the toolbar starting with Reply, > Playback...) could include the additional options for generation of > richer timestamps using a server based time reference, e.g. duration > that a given top-level entry has been active or time remaining to a > predefined alarm. > > This would require a bit more than just another button on the wave > toolbar (e.g. a dropdown or even better a floating dialog). However, I > feel that this approach could accommodate amny other use cases and > requirements related to timekeeping. As far as User Experience goes - > a gadget embedded into the wave would also be an inferior design > choice due to the need to scroll the page, which may remain rather > slow or cumbersome on portable devices. > > On Feb 8, 11:59 am, qMax <qwigly...@gmail.com> wrote: > > > > > Athttp://googlewavedev.blogspot.com/2010/02/my-extension-wish-wave-time... > > > Anna-Christina Douglas wrote: > > > I would love a collaborative timer, clock, or stopwatch that I could put > > > at the top of a wave when the meeting starts. > > > being implemented as a gadget, the timer will be updated in every > > instance of the gadget. > > which is quite wrong thing. > > > One way is: > > The gadget raise an election among gadget instances to select which > > instance will update the timer. > > The election should be reraised when the instance is closed - but how > > to determine this event? > > > Another way: > > The timer is updated by robot and the time propagated to the gadget. > > This requires cron events for every, say, second. This looks > > overwhelming. > > And is it yet possible to update a wave by cron, rather then as > > ersponce to event? -- You received this message because you are subscribed to the Google Groups "Google Wave API" group. To post to this group, send email to google-wave-...@googlegroups.com. To unsubscribe from this group, send email to google-wave-api+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=en.
