<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Yes, I meant to be referring to the MarkedComponent proposal with my T0/T1 example, but I did not call it out specifically.<div><br></div><div>In the MarkedComponent proposal, the program state per name component is (hasKey, [key], value). So, each name component becomes multi-modal (ok, bi-modal). Some have a key some do not have a key.</div><div><br></div><div>In the “use the TLV type for markers” proposal (need a spiffier name for that, but it’s what ccnx 1.0 does), the program state is (T, value). Not multi-modal.</div><div><br></div><div>Marc</div><div><br><div><div><div>On Sep 17, 2014, at 7:46 AM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr">Hi Marc<div><br></div><div>The MarkedComponent proposal <<a href="http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/000085.html">http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/000085.html</a>> is precisely a T0/T1 system:<br></div><div><ul><li>T0=NameComponent</li><li>T1=MarkedComponent</li><li>key is encoded as variable length number (same way as T)</li></ul></div><div>This still requires all codes to distinguish between NameComponent and MarkedComponent everywhere, but we'll have exactly two types, instead of potentially many types.</div><div><br></div><div>However, I agree that putting the key into TLV-TYPE is better than using MarkedComponent or having a key in every component, because the processing cost isn't any different.</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 17, 2014 at 7:36 AM, <span dir="ltr"><<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I think if you require all name components to have a “key=value” format, then that is an ok system, but it seems duplicative of having the TLV type. Personally, I would then encode the “key=“ piece the same way you encode the TLV “T” (i.e. the 1/3/5 system).<br>
<br>
Though it does seem rather duplicative of having the TLV type, as I said. I think having one T (call it T0) for non-tagged and one T (call it T1) for “key=value” introduces more overhead than is needed, as you now have two type systems for one value. You will need to keep the T0/T1 distinction everywhere in the code so you know if there is a “key=“ embedded in the name. Programmatically, you’ll probably need to sprout a new class or getter/setter for the “key=“ for those types. It seems simpler to me for the TLV “T” to always be associated with a name component, so you are always working with the (T, value) pair.<br>
<span class=""><font color="#888888"><br>
Marc<br>
</font></span><div class=""><div class="h5"><br></div></div></blockquote></div></div></div></div>
</blockquote></div><br></div></div></body></html>