<div dir="ltr">Hi Davide<div><br></div><div><font size="4">1/ targeting v0.3 or v0.4?</font></div><div>The policy is one release every three months.</div><div>According to this policy, the release date of v0.3 is projected to be Nov 25, 2014.</div>


<div><br></div><div><font size="4">
2/ submitting supporting components early</font></div><div>Nothing prevents you from submitting supporting components early.</div><div>One prior example is <a href="https://github.com/named-data/NFD/commit/02e32247ac478023c61a0f5d38e973b71f076c75" target="_blank">RttEstimator</a>. It's intended to be used by forwarding strategies in the future, but no current strategy uses it. When I submit that component, I'm almost sure that I won't be able to complete a strategy that needs RttEstimator.</div>


<div><br></div><div>I suggest you to provide a design document that explains how many components are there, their functionality and relationship.</div><div>Without this document, the necessity of components would be challenged, and you'll have a hard time getting them approved.</div>

<div><br></div><div><font size="4">3/ platform limitation</font></div><div>Platform policy requires all projects to <i>build </i>on both Ubuntu and OSX.</div><div>As I understand, if the addition of V2V face and supporting components doesn't cause a build failure, you're fine.</div>

<div>One prior example is that <a href="http://redmine.named-data.net/issues/1877#note-13">EthernetFace</a> does not support OSX with Boost 1.56.</div><div><br></div><div>If you intend to support Ubuntu and Boost 1.54 only, I suggest adding a configuration option, so that V2V face and supporting components are compiled only if "./waf configure" is executed with "--with-v2v" option.</div>

<div><br></div><div><font size="4">4/ threading</font></div><div>The decision of not to use threading comes from Van's opinion at 20140115 meeting: context switching is expensive - a context switch costs around 100 instructions.</div>

<div>Threading can be used if you can prove it's more efficient than a design without threading.</div><div><br></div><div>I personally agree that <a href="http://www.johndcook.com/blog/2014/08/17/time-exchange-rate/">it’s worth seconds of programmer time to save hours of CPU time</a>.</div>

<div>If you can illustrate that a design without threading is much more difficult to develop than a design with threading, and an implementation with threading won't become a bottleneck on V2V's typical operation environment (vehicle onboard computer), I'll agree with using threading.</div>

<div><br></div><div><font size="4">5i/ NDNLP common superclass</font></div><div>NDNLP component is already implemented individually.</div><div>If you think it's effective to make a superclass, please propose its API.</div>

<div><br></div><div><font size="4">5ii/ duplicate suppression superclass</font></div><div>If you think it's effective to make a superclass, please propose its API.<br></div><div><br></div><div><br></div><div>Yours, Junxiao</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Aug 21, 2014 at 10:25 AM, Davide Pesavento <span dir="ltr"><<a href="mailto:davide.pesavento@lip6.fr" target="_blank">davide.pesavento@lip6.fr</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">Hi guys,<br>
<br>
We recently started designing the vehicular face for NFD (basically an<br>
ad-hoc wifi face that uses raw 802.11 frames, see #1216 and related<br>
tasks), and we have some preliminary questions for you, to help us<br>
plan the design and implementation phases.<br>
<br>
1/ Is there a tentative release schedule for v0.3? Depending on it, we<br>
can decide whether submitting for v0.3 is feasible or if we should<br>
target v0.4 instead.<br>
<br>
2/ A big chunk of support code that we will have to write is fairly<br>
separate and independent from the actual V2V face and Link Adaptation<br>
Layer, for example the location service, the GPS parser, some utility<br>
classes to read digital road maps, and so on. These components are<br>
prerequisites for the vehicular face but can be developed<br>
independently. Would it be acceptable to submit them early (say for<br>
v0.3) and have them merged, even if we realize that we're unable to<br>
finish the face in time for that version?<br>
<br>
3/ Our old implementation used raw AF_PACKET sockets directly and was<br>
therefore Linux-only. We still have no interest in supporting<br>
platforms other than Linux (and possibly Android at a later time), so<br>
we'd like to know if we can keep using raw sockets.<br>
If there's opposition, we might investigate using libpcap, but this<br>
doesn't mean we will be testing the code on other platforms such as OS<br>
X, so it may or may not work.<br>
Another potential problem is that the V2V face may require boost<br>
version 1.54, when asio::generic::raw_protocol was introduced.<br>
<br>
4/ Are we allowed to use threading inside the vehicular face? (in our<br>
old design, each V2V face creates a thread where all the "layer-2.5"<br>
management operations are performed)<br>
<br>
5/ [not really a question] We identified at least two functionalities<br>
that can possibly be abstracted and factored out in a common<br>
superclass:<br>
    (i) NDNLP fragmentation, shared with EthernetFace;<br>
    (ii) Duplicate data suppression, shared with EthernetFace and<br>
MulticastUdpFace (this one might prove difficult because the<br>
suppression mechanisms that we've developed for V2V are substantially<br>
more complex).<br>
<br>
We are trying to come up with an initial design proposal ASAP,<br>
hopefully we can discuss it in person at NDNcomm.<br>
<br>
Thanks,<br>
Davide<br>
</blockquote></div><br></div></div>