NFD » ndn-cxx

This is an "oversized" issue, estimated to be 9 hours.

I find it unreasonable to split into "field declarations" and "Packet class", because what goes into field declarations would affect how methods in Packet class are implemented.

What in #2998 blocks this feature?

Reply to note-7:

Protocol requires header fields in LpPacket to appear in the order of increasing TLV-TYPE codes.

Suppose LpPacket already has header 82 and header 85, and now header 84 is being added.

It's inconvenient to maintain the order with Block::push_back and Block::erase alone; Block::insert would allow inserting header 84 before header 85.

#2998 is mostly complete but not yet merged. This issue can proceed as follows:

1. Create a local branch dev2879.
2. Locally replace encoding/block.* with files in latest commit of #2998.
3. Start development, commit locally when appropriate.
4. If you want to submit to Gerrit, mark -2 to prevent accidental merge.

When #2998 is merged:

1. Merge master branch into feature-ndnlp branch. This has to be a separate commit with minimal changes in other files.
2. Wait for the merge commit to get merged into feature-ndnlp branch.
3. In dev2879 branch, revert changes to encoding/block.*.
4. Rebase dev2879 onto feature-ndnlp.
5. Continue development.
6. Upload to Gerrit as usual. If you've previously posted -2, unset it.

Junxiao Shi wrote:

1. Locally replace encoding/block.* with files in latest commit of #2998.

There is a problem with doing this: The version of block.cpp/hpp in #2998 uses functions in other files that were merged after feature-ndnlp was split off from master. This causes the compile to fail.

#2998 is merged now. This issue should proceed as follows:

1. Merge master branch into feature-ndnlp branch. This has to be a separate commit with minimal changes in other files.
2. Wait for the merge commit to get merged into feature-ndnlp branch.
3. Develop on top of feature-ndnlp after the merge.
4. Upload to Gerrit as usual.

You MAY start development before the merge commit is approved, but then you'll have to deal with the rebasing mess.

The API and unit tests have been completed. I'm waiting on Gerrit 2254 to be merged before submitting for code review.

what's a point of waiting? Git provides enough mechanisms to update multiple commits when necessary. Rebasing or merging would not affect your new code in any way.

I cannot understand Junxiao's statements that he will need something to be meeged before he can start working on dependent code. This is not a productive development process. Working on multiple dependent commits in progress is what a lot of people including me are doing all the time.