Inconsistent enduser API

[basilkohler]

• mkContent, fillContent, fillContentWithHdr, ...
• some function do not move content to the beginning of the buffer

[tschudin]

On Wed, 29 Oct 2014, Basil Kohler wrote:

• mkContent, fillContent, fillContentWithHdr, ...
• some function do not move content to the beginning of the buffer

I decided to keep this different behavior (due to how you fill
the packet buffer) because:

a unification would, for same suites, impose a memory copy that can be
avoided.

[basilkohler]

We talked with Manolis about this topic and he was very confused as an "enduser" how these functions work and what the difference between mkContent, fillContent and so on is.

For the use inside ccn-lite these functions are fine because, as you mentioned, there are performance reasons why they are the way they are.

For endusers or the use for the util tools, they are hard to grasp at first and a "common" interface where all the function behave similar and in an expected way is the idea of this issue.

[msifalakis]

I would have flagged the issue earlier but I m caught up with work for the Autonomics course atm.

Christian, as Basil mentions if I open the current ccn-lite box with the intend to extend functionality (as is the case of omnet), I am confronted with a volume of function names seemingly doing the same thing (at least in the past it was the same function name and just the code residing in many places). If I check closer, the code inside these different functions I see behavior that I cannot comprehend why it does what it does in absence of comments or unless I take the time to read the rest of the code (I m referring to optimisations that you mention).

If ccn-lite is to be officially unsupported code-base and marginally documented, imho it should at least have an intuitive API both for the app user and the hacker that wants to extend the existing code base. One wrapper function with a flag identifying the suite and a unifying signature across suites is the minimum expectation I believe.

I sat last friday to start sketching a header with such function declarations and structs (that I wish to have available in omnet for example), but not finished it yet due to the Cs321 alerts.

[tschudin]

having a clean API would be nice, indeed. I feel like in the middle of a
refactoring effort (in order to support many protocols), and I have
worked more in an exploratory style than systematic. Any contribution is
highly welcome!

On Wed, 29 Oct 2014, msifalakis wrote:

I would have flagged the issue earlier but I m caught up with work for the
Autonomics course atm.

Christian, as Basil mentions if I open the current ccn-lite box with the
intend to extend functionality (as is the case of omnet), I am confronted with
a volume of function names seemingly doing the same thing (at least in the
past it was the same function name and just the code residing in many places).
If I check closer, the code inside these different functions I see behavior
that I cannot comprehend why it does what it does in absence of comments or
unless I take the time to read the rest of the code (I m referring to
optimisations that you mention).

If ccn-lite is to be officially unsupported code-base and marginally
documented, imho it should at least have an intuitive API both for the app
user and the hacker that wants to extend the existing code base. One wrapper
function with a flag identifying the suite and a unifying signature across
suites is the minimum expectation I believe.

I sat last friday to start sketching a header with such function declarations
and structs (that I wish to have available in omnet for example), but not
finished it yet due to the Cs321 alerts.

—
Reply to this email directly or view it on
GitHub.[ADxFAkduFz92MIIPCXWFo5m0bvdUgkNoks5nITkwgaJpZM4C0UzP.gif]

[blacksheeep]

V2 API now available