[Nfd-dev] Naming conventions for "sequence number"

[Junxiao Shi]

Dear folks

My opinion is:

The version number is a non-negative integer.
Applications SHOULD guarantee version numbers of the same collection is
monotonically increasing.
To satisfy this recommendation, applications MAY choose to generate version
numbers based on timestamps; when a version number is based on timestamp,
it SHOULD be the number of milliseconds since UNIX epoch.
Alternatively, applications MAY choose to generate version numbers from a
monotonically increasing sequence.
When multiple producers exist for the same collection, a producer SHOULD
NOT generate a version number that is less than or equal to the latest
version number to best of its knowledge.

Yours, Junxiao

On Thu, Jul 24, 2014 at 3:38 PM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:

>
> On Jul 24, 2014, at 10:06 AM, Davide Pesavento <davide.pesavento at lip6.fr>
> wrote:
>
> > Hi Alex and all,
> >
> > Some comments from me and Giulio.
> >
> > Segmentation: looks good to us.
> >
> > Versioning: must the version really correspond to the number of
> > millisecs since epoch? I can see a couple of problems with this:
> >    1/ millisecs granularity may not be enough for the application
> >    2/ if accurate clock synchronization is indeed a problem, using
> > timestamps is pointless, but on the other hand there's no defined
> > marker for non-time-based versioning, so what do we do?
> >
> > Maybe the value for the version marker should be defined more broadly
> > as a monotonically increasing nonnegative integer (but not necessarily
> > sequential), leaving the door open to more use cases. On the other
> > hand, one could argue that this new definition isn't much different
> > from a sequence number (it only lacks the sequentiality property),
> > therefore maybe we could merge versioning into sequencing. If needed,
> > applications can still use timestamps in name components, but those
> > components simply won't be marked in any special way.
>
> Hi Davide and Giulio. Thanks for the comments!
>
> The reason I'm tempted to keep the current definition of versioning is a
> little bit to do with application inter-operability in mind.  If version is
> defined as increasing number, then there is no clear definition of how
> distributed production of data can be implemented.  If producers perform
> some way of version synchronization, then only these producers will be able
> to produce the "correct" version, while third-parties will be excluded and
> not able to produce never version of the data (this is kind of a vague
> argument, but I think there could be use cases for that).  Giving a flawed,
> but simple mechanism to generate "correct" time-based version is in this
> sense better.
>
> As for dealing with applications that needs better granularity...  In some
> cases it is possible to cheat, ensuring that "version" is increased at
> least by one for the next generated data.  For other cases we definitely
> need to define some marker or some other way to give reasonable
> understanding for others about the component.
>
> > Conversely, if the majority prefers keeping the proposed timestamp
> > semantics, can we at least call it "timestamping" instead of
> > versioning?
>
> This what Lan was proposing before.  Completely replacing versioning with
> timestamping doesn't make sense for me.  Probably, we can have such a
> convention, though it should be used just for "timestamping" purposes,
> which not necessarily the same as versioning.  Also, if convention for
> timestamping is defined, we need to specify/exemplify how this could be
> used (e.g., by third-parties).
>
> ---
> Alex
>
>
> > Thanks,
> > Davide
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140724/9e1cf286/attachment.html>