On Tue, 2011-08-23 at 08:34 -0600, Joe Hildebrand wrote: > On 8/21/11 4:45 PM, "Justin Karneges" > <[email protected]> wrote: > > > Good catch, I didn't consider clock skew. I wonder if the client should > > just > > specify a timestamp 5-10m in the past instead of having magic at the node > > servers. Then accurate time queries (made relative to timestamps of other > > items provided by the server) stay optimized. > > Seems to me that client writers are more likely to incorrectly think the > server clock is going to be "right" than the other way around, but I don't > care where the skew is added as long as it's specified which side does it, > so we don't double-skew.
I'm wonder how good this would work in practice. Distributed clocks are hard. I am also not sure if you would actually need/want this in practice. Thinking aloud from here on. The use of information like User Mood and User Tune in IM clients is usually that they are just shown as icons in a roster. However, I image that most 'microblogging' applications would have a 'river of updates' UI. In this setting, I'd assume you want to limit the updates in some way (more specific types, more specific senders (not everyone on your roster), etc). Would you then still use implicit subscriptions? If not, I assume the subscription would persist over sessions, only sending out notifications based on presence. Now you need a way to exchange your client's state to each of the services that you hold subscriptions with. These RSM ids would work, but it is a cumbersome to send these out every time you come online. The only thing I could come up with is a twisted scheme were you basically do acking on received notifications. I.e. the service remembers what you got last. Hmm. -- ralphm
