[Ndn-lib] wireEncode/wireDecode interface missing in Name class

Wentao Shang 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:

>  Wentao,
>
>  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...

Wentao


>
>  Jeff
>
>
>   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
> class
>
>
>
>
> 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.
>
>  Wentao
>
>
>>
>>  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>
>> wrote:
>>
>>  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.
>>
>>  Wentao
>>
>> 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?
>>>
>>>  Thanks,
>>> - 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?
>>>
>>>  Best,
>>> Wentao
>>>
>>>  --
>>> PhD @ IRL, CSD, UCLA
>>>
>>
>>
>> --
>> PhD @ IRL, CSD, UCLA
>>
>>    _______________________________________________
>> Ndn-lib mailing list
>> Ndn-lib at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-lib
>>
>>
>
>
>  --
> PhD @ IRL, CSD, UCLA
>  _______________________________________________ Ndn-lib mailing list
> Ndn-lib at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-lib
>



-- 
PhD @ IRL, CSD, UCLA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-lib/attachments/20140412/40a77e0f/attachment.html>


More information about the Ndn-lib mailing list