Bug #4160
closed
the default time uint is millisecond while ndn-cxx uses nanosecond
0%
Description
This causes problems when programs based on ndn-ccl libraries need to communicate with problems based on ndn-cxx
Updated by Anonymous almost 7 years ago
The CCL is not meant to have the exact API as ndn-cxx. Can you give an example of communication problems?
Updated by Haitao Zhang almost 7 years ago
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.
Updated by Anonymous almost 7 years ago
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.
Updated by Haitao Zhang almost 7 years ago
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.
Updated by Jeff Burke almost 7 years ago
- 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.