NDN-CCL

This should not be "send", as semantically we are not sending anything, rather make data available if it is requested.

For the lack of a better word, i suggest sticking with put, as it was used in old codebase and is used (=is familiar to developers) in mdn-cxx library.

Just so I am clear: What are the exact semantics requested of the library / forwarder by this call? ("Send" to the forwarder / "put" in the content store) or something different?

I think what you mentioned is not semantics, rather side effects, though not sure. May be it should be just "make data packet available for the application/library and forwarder". What forwarder and app will do with the data (forward, cache, or discard) could be outside definition of the method.

May be we need some arguments to put yo indicate the desired side-effect.

Hi Jeff,

Right now, the OnInterest callback passes a Transport to the application so it can give it the data packet. We would want to change the the callback to pass a Face instead of a Transport. I'm thinking of ways to change the signature of the callback in a way where we can deprecate the old usage and add a new one.

For Python and JavaScript which don't have signatures on the callbacks, my idea in issue #2550 was to add sendData to Transport and deprecate the application calling send, so that we could add sendData to Face and it would work when the Python or JavaScript onInterest is passed a Face object instead of a Transport.

For C++ and Java, I suggest we would add new overloads of registerPrefix which take the OnInterest callback with the new signature and deprecate the previous. What do you think?

The callback interface should be a different discussion. I personally do not like that the callback is forced receive information that is not related to the interest. This forces more work for the developer

I would even go in saying that this should be just Interest (may be InterestFilter too, but not 100% convinced either way). Other parts (registered filter, face, registered id, etc.) are useful, but all of them are naturally bound in some languages (js, java, may be python) or can be explicitly bound to the callback when needed.

We will add Face.putData(data) and deprecate the application's access to Transport.send. Also the OnInterest callback given to registerPrefix should pass a Face, and deprecate the OnInterest with Transport. We name it Face.putData(data) instead of put(data) to make it work better with Python and JavaScript where it is harder to overload methods.

What exactly is the problem with python and javascript?

For example, KeyChain.sign is overloaded to sign a data buffer, an Interest and a Data. They all do very different things. In C++ each overloaded method is separate code and can be documented and followed clearly. But in Python and JavaScript the documentation and code all has to be mashed together.

https://github.com/named-data/PyNDN2/blob/17aabaeb3dd529d622bc5f3b114cb7e7e23fa8fc/python/pyndn/security/key_chain.py#L262

We are naming the method "put" instead of "send" because the library may do something other than simply send the packet. And the library will likely do something different in put for Data and put for Interest. So I prefer to keep them separate with putData, etc. It is not a burden on the application to call putData instead of put.

I'm not sure that I'm following the reasoning (I cannot foresee a need for "putInterest") and documentation may not be a big problem.

In any case. I'm ok with "Face.putData", as it would match "Face.expressInterest" name.

Question: In ndn-cxx, Face.put says "It is highly recommended to use a Data packet that was created using make_shared(...). Otherwise, put() will make an extra copy of the Data packet to ensure validity of published Data until the asynchronous put() operation finishes."
https://github.com/named-data/ndn-cxx/blob/a8659ff5709a27404e69e85e0fd27823c4abc76d/src/face.hpp#L481

But internally, the library only needs to keep the wire encoding blob until the asynchronous put() operation finishes, not the whole Data object. So can we remove the requirement to pass a shared_ptr?

Not exactly. Data packet can has other fields that are bundled with the Data (e.g., LocalControlHeader), which needs to be accessed during async operation execution.

The main reason for putData to be internally async is to ensure thread safety (essentially, every Face operation is serialized).