[Ndn-lib] wireEncode/wireDecode interface missing in Name class
wentaoshang at gmail.com
Sat Apr 12 10:06:50 PDT 2014
On Sat, Apr 12, 2014 at 9:58 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
> I'm really not sure what you mean. If the library extracts the bits of
> each name component from the TLV component, what more is needed?
If the Name is critical to the application, I think maybe it is useful to
expose both high-level abstraction and low-level detail (like wire encoded
streams). Exposing the wire format of other TLV classes may be an overkill.
In the current API, we already have wireEncode/wireDecode for Interest and
Data. But I would argue that the applications might care more about the
wire format of Names than the format of Interest/Data, if they care about
the wire format at all...
> From: Wentao Shang <wentaoshang at gmail.com>
> Date: Sat, 12 Apr 2014 09:43:09 -0700
> To: "Dave Oran (oran)" <oran at cisco.com>
> Cc: "ndn-lib at lists.cs.ucla.edu" <ndn-lib at lists.cs.ucla.edu>
> Subject: Re: [Ndn-lib] wireEncode/wireDecode interface missing in Name
> On Sat, Apr 12, 2014 at 5:17 AM, Dave Oran (oran) <oran at cisco.com> wrote:
>> This is fairly scary. What if we decide to change the wire format? Do
>> all the applications break?
> Hi Dave,
> I understand the hope is to decouple applications from wire format as
> much as possible. But it's not like in the IP world where we almost never
> touch the TCP/IP header bits in applications. In NDN the Name is shared
> information between network layer and application layer. I doubt if we can
> completely eliminate the case where app developers need to deal with the
> TLV-formatted names.
>> Maybe we're just having a terminology misunderstanding here.
>> Applications should have an API that allows them to construct and
>> deconstruct names from/to typed name components. It's the protocol stack's
>> responsibility to take those application-oriented data structures and
>> marshall/unmarshall the wire format of the name field in the messages.
>> If such an API doesn't exist that's a major hole, IMO.
>> On Apr 11, 2014, at 10:03 PM, "Wentao Shang" <wentaoshang at gmail.com>
>> One example is repo-ng, which stores names in wire format.
>> Another use case in my mind is that I want to create customized command
>> interest for ndn smart home control, which also requires dealing with wire
>> format names.
>> On Friday, April 11, 2014, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
>>> Hi Wentao,
>>> Can you say something more about how your application needs to
>>> directly manipulate the Name wire format?
>>> - Jeff T
>>> From: Wentao Shang <wentaoshang at gmail.com>
>>> Date: Friday, April 11, 2014 5:52 PM
>>> To: NDN Lib <ndn-lib at lists.cs.ucla.edu>
>>> Subject: [Ndn-lib] wireEncode/wireDecode interface missing in Name class
>>> Hi all,
>>> In NDN CCL API 0.1a2 documentation, there is no interface to directly
>>> manipulate the wire format of Name class. In some applications this feature
>>> is needed. And since Name-related operations are essential part of NDN
>>> application development, it would be nice in general to have the capability
>>> of handling wire format of Names. Any thoughts about adding this interface
>>> to the CCL API?
>>> PhD @ IRL, CSD, UCLA
>> PhD @ IRL, CSD, UCLA
>> Ndn-lib mailing list
>> Ndn-lib at lists.cs.ucla.edu
> PhD @ IRL, CSD, UCLA
> _______________________________________________ Ndn-lib mailing list
> Ndn-lib at lists.cs.ucla.edu
PhD @ IRL, CSD, UCLA
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-lib