From shijunxiao at email.arizona.edu  Mon Feb  3 09:35:51 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 3 Feb 2014 07:35:51 -1000
Subject: [Nfd-dev] NFD Design
In-Reply-To: <CAMctUDNaqxQgPo6O4VS_EvvJrZEQPosKsUt_opdnCbq4XpFu_w@mail.gmail.com>
References: <CAMctUDNaqxQgPo6O4VS_EvvJrZEQPosKsUt_opdnCbq4XpFu_w@mail.gmail.com>
Message-ID: <CAOFH+ObTGrwhZ8CsT=TzXAOkkcvvHcWaH1Vx6iC+1sp5=_dh7g@mail.gmail.com>

Hi Haowei

NFD high level design is at http://irl.cs.ucla.edu/~cawka/nfd-uml/
This document is frequently updated to reflect new thinking.

The assignee of each module (or group of modules) should design the
internal structure of that module, if UML doesn't specify that.

Yours, Junxiao
On Feb 3, 2014 5:09 AM, "Haowei Yuan" <hyuan at wustl.edu> wrote:

> Hi Alex,
>
> I was wondering what the status of the NFD design is, would there be a
> release of the updated design soon? And what would the next steps be
> for the developers?
>
> Thanks,
> Haowei
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140203/69366c94/attachment.html>

From bzhang at cs.arizona.edu  Mon Feb  3 10:28:32 2014
From: bzhang at cs.arizona.edu (Beichuan Zhang)
Date: Mon, 3 Feb 2014 11:28:32 -0700
Subject: [Nfd-dev] NFD Design
In-Reply-To: <CAOFH+ObTGrwhZ8CsT=TzXAOkkcvvHcWaH1Vx6iC+1sp5=_dh7g@mail.gmail.com>
References: <CAMctUDNaqxQgPo6O4VS_EvvJrZEQPosKsUt_opdnCbq4XpFu_w@mail.gmail.com>
	<CAOFH+ObTGrwhZ8CsT=TzXAOkkcvvHcWaH1Vx6iC+1sp5=_dh7g@mail.gmail.com>
Message-ID: <B129E676-E9CA-4411-A2B0-846DD1162BD8@cs.arizona.edu>

Haowei and all,

Alex and Junxiao have been updating the design and have done a mockup implementation, which supports a subset of planned functionality and uses simple data structures. The code now can compile and forward packets. The purpose of this mockup design is to make it easier for people to understand the design as well as fill in their code for better performance and more complete functionality.

With the mockup done, the next step is for everyone on this list to help code the rest of NFD. Alex and Junxiao have already created many tasks on redmine. I?m going through them today, and will send out a tentative assignment and schedule by the end of today, so everyone can get started.

We use gerrit.named-data.net for code repository and review, and redmine.named-data.net for project management. The redmine site has links to all the up-to-date information. I highly encourage everyone to take a look at these and get ready for NFD development.

Thanks,

?
beichuan


On Feb 3, 2014, at 10:35 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Hi Haowei
> 
> NFD high level design is at http://irl.cs.ucla.edu/~cawka/nfd-uml/
> This document is frequently updated to reflect new thinking.
> 
> The assignee of each module (or group of modules) should design the internal structure of that module, if UML doesn't specify that.
> 
> Yours, Junxiao
> 
> On Feb 3, 2014 5:09 AM, "Haowei Yuan" <hyuan at wustl.edu> wrote:
> Hi Alex,
> 
> I was wondering what the status of the NFD design is, would there be a
> release of the updated design soon? And what would the next steps be
> for the developers?
> 
> Thanks,
> Haowei
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140203/9fc6a120/attachment.html>

From bzhang at cs.arizona.edu  Mon Feb  3 15:14:47 2014
From: bzhang at cs.arizona.edu (Beichuan Zhang)
Date: Mon, 3 Feb 2014 16:14:47 -0700
Subject: [Nfd-dev] plan and assignments
Message-ID: <A6039168-29A0-4482-AFF2-3E0576910684@cs.arizona.edu>

Hi All,

As I mentioned in a previous email, Alex and Junxiao have done a mockup implementation, which will serve as a starting point towards a complete NFD first release. We?re now ready to engage all programmers in this effort. Here I?ll give a time table, a tentative assignment list, and how to get started. However, many things are still in flux and I?m sure there will be a lot of questions. Please, communicate with Alex, Junxiao, and me as early as possible when there is an issue or any confusion. 

If you go to redmine site and click on the ?Issues? tab, there?re already many tasks, which belong to a few categories. I?m assigning names to each category based on my understanding of people?s research work and interest:

- Management: Steve/Susmit (CSU)
- PIT and FIB: Haowei (WashU), Tian (BIT)
- CS: Ilya (UCLA)
- Forwarding: Junxiao (Arizona)
- Faces: Davide/Giulio (UCLA)
- Core: Alex (UCLA), Junxiao (Arizona)
- Build: Yi Huang (Arizona)
- Tools: Jerald (Arizona), Hila (WashU)
- Library: Alex/Yingdi/Wentao (UCLA)
- Routing (nrd): Obaid (Memphis)

If you see any problem with this assignment, please let us know asap.

For the category assigned to you, please start working on the design, specification, and implementation. There?re a few things to note:

- We use the redmine site for project management. 

The unit of management is a task, which is a relatively self-contained piece of work that can be done in a couple of hours or at most a few days. Too big a task may block other people?s progress. The work can be design, specification, and/or coding. 

Anyone can create a task, spell out dependency, assign it to self or other people, update the status, make comments, report progress in %, etc. You can also configure redmine to send you emails regarding your tasks or any tasks you?re interested.

We rely on your timely report to redmine to keep track of who?s doing what and the progress. So when you work on something, please create the task, make the assignment, update regularly, and respond to redmine comments timely.

- We use Gerrit for code review. 

Unit tests are required for every code submission. Please make sure to write unit tests with reasonable code coverage.

- The wiki tab on the redmine site has links to some resources, especially protocol specification and ccnx documents. In a number of cases (e.g., tables), you should take ccnx design as the starting point. There may be some isolated improvements, but if there?re major structural changes, we need discuss first. 

- If you?re not familiar with the design and code structure yet, I?d suggest to start with getting ping working.

Jerald has migrated ndnping (https://github.com/jeraldabraham/ndn-tlv-ping) to use TLV format, and Alex has done ndnd-tlv which translates between TLV and ccnb. You may want to (1) install and setup ndnping with ndnd-tlv, make sure it work, and then (2) on the client side use the mockup NFD to replace the ndnd-tlv. Once this is done, it gives you a minimally functioning NFD, so you can play with it and figure out how it works and where your code should fill in.

We?re operating under a tight timeline. After the mockup, we want the actual implementation done by March 1, and leave about two weeks in March for tests on the NDN testbed. So we have about 4 weeks in February for major coding and debugging. It?s tight, but  with all the research and preparation this group has done in the past few years, I think we can pull it off. If you have any questions, please contact Alex/Junxiao/me ASAP.

Thanks!

?
beichuan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140203/b3b42d17/attachment.html>

From shijunxiao at email.arizona.edu  Sun Feb  9 18:34:51 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 9 Feb 2014 19:34:51 -0700
Subject: [Nfd-dev] canonical repository of ndn-cpp-dev
Message-ID: <CAOFH+Obd2uaEiZo-Vt75XLJCOP4P=-yfKbiGRhqvAHunL17M0A@mail.gmail.com>

Hi Alex

Previously, developers are using GitHub cawka/ndn-cpp repository, new-dev
branch for ndn-cpp-dev library.
Commit b35bcf2874eeab69b04cf6e0ac2ec3cb8004612d instructs Travis CI to use
GitHub named-data/ndn-cpp-dev repository, master branch for ndn-cpp-dev
library.
Should developers also switch to this repository?

Is it permissible to install ndn-cpp-dev through Macports?

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140209/a7f5c900/attachment.html>

From alexander.afanasyev at ucla.edu  Sun Feb  9 20:21:05 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Sun, 9 Feb 2014 20:21:05 -0800
Subject: [Nfd-dev] canonical repository of ndn-cpp-dev
In-Reply-To: <CAOFH+Obd2uaEiZo-Vt75XLJCOP4P=-yfKbiGRhqvAHunL17M0A@mail.gmail.com>
References: <CAOFH+Obd2uaEiZo-Vt75XLJCOP4P=-yfKbiGRhqvAHunL17M0A@mail.gmail.com>
Message-ID: <461D76A2-D643-4927-A5DE-1EB3523B01BC@ucla.edu>

Yes. We should start using named-data/ndn-cpp-dev, but I'm keeping both repos in sync for now.

As for macports, no.  There are many things that are changing in ndn-cpp-dev (including some API things), so the library needs to be compiled from source.

---
Alex

On Feb 9, 2014, at 6:34 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Hi Alex
> 
> Previously, developers are using GitHub cawka/ndn-cpp repository, new-dev branch for ndn-cpp-dev library.
> Commit b35bcf2874eeab69b04cf6e0ac2ec3cb8004612d instructs Travis CI to use GitHub named-data/ndn-cpp-dev repository, master branch for ndn-cpp-dev library.
> Should developers also switch to this repository?
> 
> Is it permissible to install ndn-cpp-dev through Macports?
> 
> Yours, Junxiao




From afanasev at cs.ucla.edu  Thu Feb 13 21:29:35 2014
From: afanasev at cs.ucla.edu (Alex Afanasyev)
Date: Thu, 13 Feb 2014 21:29:35 -0800
Subject: [Nfd-dev] jenkins build bot
Message-ID: <57D66570-37A0-40B6-A722-F9D890943135@cs.ucla.edu>

Those who have logged in before to our build bot.  We changed the URL and now it is http://jenkins.named-data.net.  As a result of this change, all openID accounts became invalid, so I have deleted them and you will need to re-login again.

If you have problem, let me know.

--
Alex


From shijunxiao at email.arizona.edu  Sat Feb 15 10:34:15 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sat, 15 Feb 2014 11:34:15 -0700
Subject: [Nfd-dev] code style rule 44
Message-ID: <CAOFH+ObATc74samRKWwUW7YeDFAMqJa=WXDH14EDpp1+i6mWrQ@mail.gmail.com>

Hi Alex

I need clarification on code guidelines rule 44:

44. (C, C++, C# and Java only) Type conversions must always be done
explicitly. Never rely on implicit type conversion.
floatValue = (float)intValue; // NOT: floatValue = intValue;
By this, the programmer indicates that he is aware of the different types
involved and that the mix is intentional.



Which of the following are allowed?

//01
std::string x = "example"; // char[] is implicitly converted to std::string

//02
uint64_t n = 1 + 1; // int is implicitly converted to uint64_t

//03
uint64_t a = static_cast<uint64_t>(1);
uint32_t b = static_cast<uint32_t>(2);
if (a == b) { // uint32_t is implicitly converted to uint64_t
}

//04
void func(std::string x);
func("example"); // char[] is implicitly converted to std::string

//05
uint8_t x = tlv::Interest; // enum is implicitly converted to uint8_t

//06
int x = 1;
float y = x;


My opinion is to allow:

   - numeric literals and enum members to any numeric type
      - allows 02 05 above
   - implicit conversion from T[] to std::basic_string<T>
      - allows 01 04 above

and disallow:

   - implicit conversion between numeric types
      - disallows 03 06 above
   - use of implicit constructors (in most cases)
   - This also means constructor taking one argument should be marked
      explicit.
      - use of implicit conversion operators (in most cases)


Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140215/de89a503/attachment.html>

From alexander.afanasyev at ucla.edu  Sat Feb 15 19:52:41 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Sat, 15 Feb 2014 19:52:41 -0800
Subject: [Nfd-dev] code style rule 44
In-Reply-To: <CAOFH+ObATc74samRKWwUW7YeDFAMqJa=WXDH14EDpp1+i6mWrQ@mail.gmail.com>
References: <CAOFH+ObATc74samRKWwUW7YeDFAMqJa=WXDH14EDpp1+i6mWrQ@mail.gmail.com>
Message-ID: <3293AA7B-3E94-4747-A29E-66FC0D58940F@ucla.edu>

This rule is very strange and I don't like following it.  Implicit conversions generally a good thing.  For the cases implicit conversion is undesirable, constructors should be mark explicit.

I don't see problems with any of the listed examples, except with enum (some compiler may issue warnings).

I prefer not considering this rule for us.

---
Alex


On Feb 15, 2014, at 10:34 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Hi Alex
> 
> I need clarification on code guidelines rule 44:
> 44. (C, C++, C# and Java only) Type conversions must always be done explicitly. Never rely on implicit type conversion.
> floatValue = (float)intValue; // NOT: floatValue = intValue;
> By this, the programmer indicates that he is aware of the different types involved and that the mix is intentional.
> 
> 
> Which of the following are allowed?
> 
> //01
> std::string x = "example"; // char[] is implicitly converted to std::string
> 
> //02
> uint64_t n = 1 + 1; // int is implicitly converted to uint64_t
> 
> //03
> uint64_t a = static_cast<uint64_t>(1);
> uint32_t b = static_cast<uint32_t>(2);
> if (a == b) { // uint32_t is implicitly converted to uint64_t
> }
> 
> //04
> void func(std::string x);
> func("example"); // char[] is implicitly converted to std::string
> 
> //05
> uint8_t x = tlv::Interest; // enum is implicitly converted to uint8_t
> 
> //06
> int x = 1;
> float y = x;
> 
> 
> My opinion is to allow:
> numeric literals and enum members to any numeric type
> allows 02 05 above
> implicit conversion from T[] to std::basic_string<T>
> allows 01 04 above
> and disallow:
> implicit conversion between numeric types
> disallows 03 06 above
> use of implicit constructors (in most cases)
> This also means constructor taking one argument should be marked explicit.
> use of implicit conversion operators (in most cases)
> 
> Yours, Junxiao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140215/abe5a39d/attachment.html>

From shijunxiao at email.arizona.edu  Sat Feb 15 20:17:39 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sat, 15 Feb 2014 21:17:39 -0700
Subject: [Nfd-dev] code style rule 44
In-Reply-To: <3293AA7B-3E94-4747-A29E-66FC0D58940F@ucla.edu>
References: <CAOFH+ObATc74samRKWwUW7YeDFAMqJa=WXDH14EDpp1+i6mWrQ@mail.gmail.com>
	<3293AA7B-3E94-4747-A29E-66FC0D58940F@ucla.edu>
Message-ID: <CAOFH+Ob48xGT=-WUGDpXN5=oXL25dmBpf2hwYTh08=n1=b2Uew@mail.gmail.com>

Dear folks

Implicit conversion between integer and floating point numbers can cause
problems and should be avoided.

Implicit conversion in single-argument constructor is usually undesirable.
Therefore, all single-argument constructors should be marked 'explicit',
unless implicit conversion IS desirable. In the few cases that implicit
conversion is desirable, a comment should be placed near the constructor
documenting the reason.

Yours, Junxiao

On Sat, Feb 15, 2014 at 8:52 PM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:

> This rule is very strange and I don't like following it.  Implicit
> conversions generally a good thing.  For the cases implicit conversion is
> undesirable, constructors should be mark explicit.
>
> I don't see problems with any of the listed examples, except with enum
> (some compiler may issue warnings).
>
> I prefer not considering this rule for us.
>
> ---
> Alex
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140215/a50c8079/attachment.html>

From alexander.afanasyev at ucla.edu  Sat Feb 15 20:31:07 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Sat, 15 Feb 2014 20:31:07 -0800
Subject: [Nfd-dev] code style rule 44
In-Reply-To: <CAOFH+Ob48xGT=-WUGDpXN5=oXL25dmBpf2hwYTh08=n1=b2Uew@mail.gmail.com>
References: <CAOFH+ObATc74samRKWwUW7YeDFAMqJa=WXDH14EDpp1+i6mWrQ@mail.gmail.com>
	<3293AA7B-3E94-4747-A29E-66FC0D58940F@ucla.edu>
	<CAOFH+Ob48xGT=-WUGDpXN5=oXL25dmBpf2hwYTh08=n1=b2Uew@mail.gmail.com>
Message-ID: <95445C87-53BA-4E6D-B9DD-E2B8498935B8@ucla.edu>

There are some general cases when implicit conversion is standard and does not require any comment.  For example, it is the case with "const std::string&" parameter and all safe value preserving integer upconversions (from uint8 to uint32, etc.).

---
Alex

On Feb 15, 2014, at 8:17 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Dear folks
> 
> Implicit conversion between integer and floating point numbers can cause problems and should be avoided.
> 
> Implicit conversion in single-argument constructor is usually undesirable. Therefore, all single-argument constructors should be marked 'explicit', unless implicit conversion IS desirable. In the few cases that implicit conversion is desirable, a comment should be placed near the constructor documenting the reason.
> 
> Yours, Junxiao
> 
> On Sat, Feb 15, 2014 at 8:52 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
> This rule is very strange and I don't like following it.  Implicit conversions generally a good thing.  For the cases implicit conversion is undesirable, constructors should be mark explicit.
> 
> I don't see problems with any of the listed examples, except with enum (some compiler may issue warnings).
> 
> I prefer not considering this rule for us.
> 
> ---
> Alex
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140215/e4ea8f8d/attachment.html>

From shijunxiao at email.arizona.edu  Tue Feb 25 17:36:55 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 25 Feb 2014 18:36:55 -0700
Subject: [Nfd-dev] NFD CodeStyle rule 26
Message-ID: <CAOFH+OZ_bPJshVbAWBEKrEOcG40D=k1m3qWut-4nt-WBTAXhJA@mail.gmail.com>

Hi Alex

Rule 26 states: Complement names must be used for complement operations
An example given is "insert/delete".
However, "delete" is a reserved word in C++, which cannot be used as an
identifier.

I suggest changing this to "insert/erase" to match STL style.


Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140225/73fe7c08/attachment.html>

From afanasev at cs.ucla.edu  Tue Feb 25 17:45:35 2014
From: afanasev at cs.ucla.edu (Alex Afanasyev)
Date: Tue, 25 Feb 2014 17:45:35 -0800
Subject: [Nfd-dev] NFD CodeStyle rule 26
In-Reply-To: <CAOFH+OZ_bPJshVbAWBEKrEOcG40D=k1m3qWut-4nt-WBTAXhJA@mail.gmail.com>
References: <CAOFH+OZ_bPJshVbAWBEKrEOcG40D=k1m3qWut-4nt-WBTAXhJA@mail.gmail.com>
Message-ID: <800D3230-DB0F-4F01-9B2B-11A0DEE0A96F@cs.ucla.edu>

will this imply changing all the code and protocols?

If so, I would rather prefer allowing insert/erase pair (as preferred).

---
Alex

On Feb 25, 2014, at 5:36 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Hi Alex
> 
> Rule 26 states: Complement names must be used for complement operations
> An example given is "insert/delete".
> However, "delete" is a reserved word in C++, which cannot be used as an identifier.
> 
> I suggest changing this to "insert/erase" to match STL style.
> 
> 
> Yours, Junxiao




From shijunxiao at email.arizona.edu  Tue Feb 25 23:34:52 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 26 Feb 2014 00:34:52 -0700
Subject: [Nfd-dev] NFD CodeStyle rule 26
In-Reply-To: <800D3230-DB0F-4F01-9B2B-11A0DEE0A96F@cs.ucla.edu>
References: <CAOFH+OZ_bPJshVbAWBEKrEOcG40D=k1m3qWut-4nt-WBTAXhJA@mail.gmail.com>
	<800D3230-DB0F-4F01-9B2B-11A0DEE0A96F@cs.ucla.edu>
Message-ID: <CAOFH+OZuudUGFjRgFvUp2NYKZPESOO7AYPdJLsozmp9=h-G1=w@mail.gmail.com>

Dear folks

Protocols should still use insert/delete because protocols are
language-neutral.

FIB/PIT/CS currently have insert/remove. They should be changed to
insert/erase.

Yours, Junxiao

On Tue, Feb 25, 2014 at 6:45 PM, Alex Afanasyev <afanasev at cs.ucla.edu>wrote:

> will this imply changing all the code and protocols?
>
> If so, I would rather prefer allowing insert/erase pair (as preferred).
>
> ---
> Alex
>
> On Feb 25, 2014, at 5:36 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> > Hi Alex
> >
> > Rule 26 states: Complement names must be used for complement operations
> > An example given is "insert/delete".
> > However, "delete" is a reserved word in C++, which cannot be used as an
> identifier.
> >
> > I suggest changing this to "insert/erase" to match STL style.
> >
> >
> > Yours, Junxiao
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140226/26c0f3b5/attachment.html>