Rename sequence_number to timestamp.

Rename sequence_number to timestamp.

The sequence_number field is used to send events timestamp. That name
was confusing. Renamed sequence_number to timestamp in EventMessage
and latest_sequence_number to last_event_timestamp in VideoPacket.

TBR=nasko@chromium.org

Committed: https://crrev.com/c258bd4b0dcde95617cada14aa5dc154d456b943
Cr-Commit-Position: refs/heads/master@{#310592}

[Sergey Ulanov, 2015-01-06 18:49:28]

sergeyu@chromium.org changed reviewers:
+ wez@chromium.org

[Wez, 2015-01-06 21:54:35]

The intention in having the sequence-number field is that the client can use any
arbitrary sequencing that it wishes; there is no contract between client & host
requiring that the field be an actual timestamp - timestamps are an
implementation detail; just one potential form of sequence the client might use.

So the client-side implementation should definitely use "timestamp" terminology,
but the protocol & host implementation still really wants to be
"sequence_number".

[Jamie, 2015-01-06 22:25:36]

On 2015/01/06 21:54:35, Wez wrote:
> The intention in having the sequence-number field is that the client can use
any
> arbitrary sequencing that it wishes; there is no contract between client &
host
> requiring that the field be an actual timestamp - timestamps are an
> implementation detail; just one potential form of sequence the client might
use.
> 
> So the client-side implementation should definitely use "timestamp"
terminology,
> but the protocol & host implementation still really wants to be
> "sequence_number".

I don't have an opinion about which terminology should be used, but using
different names for the same thing at the client and host sounds like a
potential source for confusion. I think we should be consistent.

[Sergey Ulanov, 2015-01-06 22:29:04]

On 2015/01/06 21:54:35, Wez wrote:
> The intention in having the sequence-number field is that the client can use
any
> arbitrary sequencing that it wishes; there is no contract between client &
host
> requiring that the field be an actual timestamp - timestamps are an
> implementation detail; just one potential form of sequence the client might
use.
> 
> So the client-side implementation should definitely use "timestamp"
terminology,
> but the protocol & host implementation still really wants to be
> "sequence_number".

The protobuf structs are shared between host and client, so host and client have
to use the same terms on that level. Calling these fields differently on host
and client sides would make sense if the host and client were not sharing any
code and we were trying to maintain compatibility with multiple client
implementations, but we don't, so using different terms on both ends only
creates confusion. We never used the "sequence number" field for anything but
timestamps, and we can always rename this field if we ever decide to use it for
something else.

[Wez, 2015-01-07 22:24:29]

On 2015/01/06 22:29:04, Sergey Ulanov wrote:
> On 2015/01/06 21:54:35, Wez wrote:
> > The intention in having the sequence-number field is that the client can use
> any
> > arbitrary sequencing that it wishes; there is no contract between client &
> host
> > requiring that the field be an actual timestamp - timestamps are an
> > implementation detail; just one potential form of sequence the client might
> use.
> > 
> > So the client-side implementation should definitely use "timestamp"
> terminology,
> > but the protocol & host implementation still really wants to be
> > "sequence_number".
> 
> The protobuf structs are shared between host and client, so host and client
have
> to use the same terms on that level. Calling these fields differently on host
> and client sides would make sense if the host and client were not sharing any
> code and we were trying to maintain compatibility with multiple client
> implementations, but we don't, so using different terms on both ends only
> creates confusion. We never used the "sequence number" field for anything but
> timestamps, and we can always rename this field if we ever decide to use it
for
> something else.

OK, fair enough. :)

[Wez, 2015-01-07 23:56:19]

lgtm

https://codereview.chromium.org/836183002/diff/1/remoting/client/software_vid...
File remoting/client/software_video_renderer.h (right):

https://codereview.chromium.org/836183002/diff/1/remoting/client/software_vid...
remoting/client/software_video_renderer.h:76: int64 last_event_timestamp_;
s/last/latest

https://codereview.chromium.org/836183002/diff/1/remoting/host/chromoting_mes...
File remoting/host/chromoting_messages.h (right):

https://codereview.chromium.org/836183002/diff/1/remoting/host/chromoting_mes...
remoting/host/chromoting_messages.h:164: IPC_STRUCT_MEMBER(int64,
last_event_timestamp)
s/last/latest

https://codereview.chromium.org/836183002/diff/1/remoting/host/video_scheduler.h
File remoting/host/video_scheduler.h (right):

https://codereview.chromium.org/836183002/diff/1/remoting/host/video_schedule...
remoting/host/video_scheduler.h:119: void SetLastEventTimestamp(int64
last_event_timestamp);
s/Last/Latest

Or rename this to OnEventTimestamp()?

https://codereview.chromium.org/836183002/diff/1/remoting/proto/video.proto
File remoting/proto/video.proto (right):

https://codereview.chromium.org/836183002/diff/1/remoting/proto/video.proto#n...
remoting/proto/video.proto:58: // The timestamp of the latest event received
from the client.
nit: Clarify that this isn't a client-based timestamp, and may bear no relation
to the host's idea of time?

[Sergey Ulanov, 2015-01-08 17:40:26]

https://codereview.chromium.org/836183002/diff/1/remoting/client/software_vid...
File remoting/client/software_video_renderer.h (right):

https://codereview.chromium.org/836183002/diff/1/remoting/client/software_vid...
remoting/client/software_video_renderer.h:76: int64 last_event_timestamp_;
On 2015/01/07 23:56:19, Wez wrote:
> s/last/latest

Done.

https://codereview.chromium.org/836183002/diff/1/remoting/host/chromoting_mes...
File remoting/host/chromoting_messages.h (right):

https://codereview.chromium.org/836183002/diff/1/remoting/host/chromoting_mes...
remoting/host/chromoting_messages.h:164: IPC_STRUCT_MEMBER(int64,
last_event_timestamp)
On 2015/01/07 23:56:19, Wez wrote:
> s/last/latest

Done.

https://codereview.chromium.org/836183002/diff/1/remoting/host/video_scheduler.h
File remoting/host/video_scheduler.h (right):

https://codereview.chromium.org/836183002/diff/1/remoting/host/video_schedule...
remoting/host/video_scheduler.h:119: void SetLastEventTimestamp(int64
last_event_timestamp);
On 2015/01/07 23:56:19, Wez wrote:
> s/Last/Latest
> 
> Or rename this to OnEventTimestamp()?

Done.

https://codereview.chromium.org/836183002/diff/1/remoting/proto/video.proto
File remoting/proto/video.proto (right):

https://codereview.chromium.org/836183002/diff/1/remoting/proto/video.proto#n...
remoting/proto/video.proto:58: // The timestamp of the latest event received
from the client.
On 2015/01/07 23:56:19, Wez wrote:
> nit: Clarify that this isn't a client-based timestamp, and may bear no
relation
> to the host's idea of time?

Done.

[Sergey Ulanov, 2015-01-08 19:20:52]

The CQ bit was checked by sergeyu@chromium.org

[commit-bot: I haz the power, 2015-01-08 19:22:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/836183002/40001

[commit-bot: I haz the power, 2015-01-08 19:32:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-01-08 19:32:19]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Sergey Ulanov, 2015-01-08 19:43:24]

sergeyu@chromium.org changed reviewers:
+ nasko@chromium.org

[Sergey Ulanov, 2015-01-08 19:43:47]

+nasko@chromium.org in TBR for the rename in chromoting_messages.h

[Sergey Ulanov, 2015-01-08 19:43:59]

The CQ bit was checked by sergeyu@chromium.org

[commit-bot: I haz the power, 2015-01-08 19:45:58]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/836183002/60001

[commit-bot: I haz the power, 2015-01-08 20:58:34]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-01-08 20:59:30]

Patchset 4 (id:??) landed as
https://crrev.com/c258bd4b0dcde95617cada14aa5dc154d456b943
Cr-Commit-Position: refs/heads/master@{#310592}