Bug #4160
closed
the default time uint is millisecond while ndn-cxx uses nanosecond
Added by Haitao Zhang over 7 years ago.
Updated over 7 years ago.
Description
This causes problems when programs based on ndn-ccl libraries need to communicate with problems based on ndn-cxx
The CCL is not meant to have the exact API as ndn-cxx. Can you give an example of communication problems?
For example, a timestamp component is created using jNDN's Component.fromTimestamp(); when it is converted back to timestamp using ndn-cxx's Component.toTimestamp(), the timestamp is 1/1000 of the original timestamp.
Actually, the jNDN fromTimestamp and toTimestamp just encode and decode the number that it is given, without converting them. The timestamp is defined to be "Number of microseconds since UNIX epoch" in the Name Conventions document: http://named-data.net/doc/tech-memos/naming-conventions.pdf
ndn-cxx uses Boost time functions which force things to nanoseconds. But jNDN doesn't use Boost. The Common Client Libraries API is designed to be consistent across languages like Java, Python, etc. It is not hard-wired to Boost like ndn-cxx.
I need to correct myself first: ndn-cxx uses "microseconds", which is consistent with the Name Conventions document; while ccl uses "milliseconds".
I agree that it's a good that ccl libs API is designed to be consistent. My concern is, a timestamp component is interpreted differently by ndn-cxx and ccl; however, in theory, all interpretations should be consistent with the Name Conventions document.
- Status changed from New to Rejected
This is not a bug, it is an API design decision. The API calls perform as documented and encode/decode the correct convention.
Also available in: Atom
PDF