Activity
From 02/09/2015 to 03/10/2015
03/10/2015
-
10:36 PM Task #2579: Provide send/sendData in Face() and deprecate in Transport
- I'm not sure that I'm following the reasoning (I cannot foresee a need for "putInterest") and documentation may not b...
-
03:56 PM
Task #2579: Provide send/sendData in Face() and deprecate in Transport
- For example, KeyChain.sign is overloaded to sign a data buffer, an Interest and a Data. They all do very different th...
-
04:53 PM
Bug #2015 (Closed): name.toUri() does not return a valid URI: missing scheme
- Following note 1, added an optional param includeScheme.
-
03:25 PM
Task #1921 (In Progress): Provide equivalent to NDN_MAX_PACKET_SIZE
- In NDN-CPP branch issue/1921-NDN_MAX_PACKET_SIZE, added static inline method getMaxNdnPacketSize(). Noted that expres...
03/09/2015
-
02:05 PM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder
- s/architecture/nfd/g. The point of the question is less the phrasing and more a request to specific if/how the libra...
-
- This is not architectural question. This is an artifact of current implementation. If NDN was a networking stack em...
-
01:15 PM
Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder
- Hello Beichuan. We assigned this to you to see if you can bring this up as an architectural question. Should the appl...
-
- Why is it assigned to me?
The only logical way is to not include something into packets if it wasn't specified by ... -
- So, if the field is unspecified, it should not show up in the Interest at all? (This is fine, but is this part of th...
-
- What exactly is the problem with python and javascript?
-
01:22 PM
Task #2579: Provide send/sendData in Face() and deprecate in Transport
- We will add Face.putData(data) and deprecate the application's access to Transport.send. Also the OnInterest callbac...
-
01:25 PM
Feature #2568 (Closed): Face.put(Data)
- Feature #2627 was created for the issue to group high-level operations. And we have task #2579 for adding the method ...
-
- I disagree with closing of the issues that are open ended and may need to be discussed later. Closing them basically...
-
- This approach is taken in NDN-CCL for clarity in typeless languages. (Re-open with design motivation and solution th...
-
- JeffB/JeffT agree. JeffT will look at implementing in jNDN first. May need some discussion.
-
- JeffT will document why this exists across NDN-CCL and what the long-term plan is for using it. Then we can discuss.
-
- This is internal detail. So far, I talked specifically about LocalControlHeader encoding/decoding.
-
- Alex, can you make this more specific? Thanks...
-
- From AlexA: "some of the common high-level operations for Interest and Data packets needs to be grouped under the umb...
-
- Sorry, my mistake - I forgot it was in jNDN.
This will be deprecated, then removed as #2624 is completed; a note w... -
- Current implementation, does not follow the semantics of NDN packet format, where by default interests request any da...
-
- Closing unless there is a proposed benefit to the ndn-cxx approach or a drawback to the jNDN approach? (Re-open if t...
-
- My opinion is that it shouldn't. These are flags for RIB/FIB. The application dispatch can always use InterestFilte...
-
06:19 AM
Feature #2566: Implement Face.setInterestFilter
- (a question from a related issue) Should setInterestFilter follow the behavior of child inherit and capture which wer...
-
10:23 AM
Task #2368 (Closed): In security library, support KeyParams
- KeyParams is added to all libraries.
-
06:39 AM
Task #2368 (In Progress): In security library, support KeyParams
03/08/2015
-
- Deprecate ndnx packet format support in next platform release, remove code in subsequent platform release.
03/06/2015
-
- This issue is NOT CCL and has limited relation to "deprecating" of other packet support: why if I didn't specify Must...
-
- I created this in jndn. In my opinion, jndn should not have had support for ndnx as it was deprecated at the time of...
-
- I personally prefer this to be implemented in jNDN, as it is what has high priority for android applications.
-
- This should not be part of CCL at all, neither CCL should say anything about transports (may be just general about tr...
-
- I created this issue for jndn, as it applies specifically there. It is not related to NDN-CCL.
Without code refac... -
- One form (2) is a convenience method to do prefix registration and setting up dispatch.
Form (1) is just to set up... -
12:40 PM
Feature #2531 (Closed): LocalControlHeader
- I added integration test TestLocalControlHeader. Merged to master.
-
11:06 AM
Feature #2531: LocalControlHeader
- I take that back. The documentation says that the enable local control header command only affects the face which rec...
-
11:03 AM
Feature #2531: LocalControlHeader
- The integration test would have to modify NFD to send LocalControlHeader packets. So I'm going to delay writing the i...
03/05/2015
-
05:43 PM
Feature #2532 (Closed): Remote Prefix Registration
- Branch 'remote-prefix-registration' merged.
-
03:33 AM
Feature #2532: Remote Prefix Registration
- As suggested, I moved TestRemotePrefixRegistration from integration-tests to examples.
-
05:40 PM
Feature #2531: LocalControlHeader
- I want to write an integration test and merge tomorrow.
Since you said you don't need to set the outgoing Interest... -
04:06 PM Feature #2531: LocalControlHeader
- Makes sense. When are you thinking of merging and releasing?
-
03:51 PM
Feature #2531: LocalControlHeader
- > why don't we just expose one getter/setter, e.g. getLocalControlHeader() ... it would be consistent with how getMet...
-
- Looks good to me. (One minor question re: Data/Interest API: why don't we just expose one getter/setter, e.g. getLoca...
-
11:40 AM
Feature #2531: LocalControlHeader
- Hi Andrew. Please check out the branch issue/2531-LocalControlHeader: https://github.com/named-data/jndn/commits/issu...
-
- I have no issues with porting. I cannot fully agree that this is related to NDN-CCL. This is just an utility helper...
-
03:37 PM
Task #2543 (In Progress): Port SegmentFetcher
- Ported SegmentFetcher to jNDN and made TestListRib, etc. use it.
-
11:20 AM
Task #2620 (Closed): Interest setter methods should return this
- In the Data class, the setter methods like setName() return this so that you can chain calls to update values. http:/...
03/04/2015
-
- +1 to consider this. Moving to NDN-CCL unless there is a need to consider it in jNDN first.
-
- Could you explain why?
Moving to NDN-CCL unless there is a reason to only look at this in jNDN. -
- Moving to NDN-CCL unless there's a reason to consider in jNDN first?
-
- I can see the point on this and will have to revisit with JeffT what the original motivation was for the Node. (We h...
-
- +1, we will work on this.
-
- NDN-CCL issue. Essentially duplicates #2575. Related to deprecating support for NDNx. See responses to other related...
-
- Please respond to my email about a process for this, send 10/10/14 and resent 10/26/14, 1/12/15, 3/4/15.
-
- This is not a jNDN specific issue. Moved to NDN-CCL.
-
- This requires deprecating AnswerOriginKind support in NDN-CCL (or at least jNDN) and phasing out the NDNx packet form...
-
- +1 but does it need to be considered across all CCL?
-
- The basis for design for jndn is NDN-CCL, not ndn-cxx. Should we move this to a NDN-CCL issue and discuss more broad...
-
- To resolve AlexA's points earlier -
Agreed that the logic and state for isLocal() goes in Transport().
Each ... -
- Good point, it's more an example than a test. Because it has some setup involved (potentially modifying the NFD confi...
-
11:14 AM
Feature #2532: Remote Prefix Registration
- Ah, now I see the documentation in the Java file. It is clear enough. I was able to run it. It registers a prefix and...
-
- Jeff, the syntax for running the integration test should be `mvn test -DclassName=TestRemotePrefixRegistration -Dip=[...
-
08:56 AM
Feature #2532: Remote Prefix Registration
- Hi Andrew. Your existing pull request https://github.com/named-data/jndn/pull/6 adds a Face method isLocal() which si...
-
- Can you expand on this?
03/03/2015
-
04:04 PM
Feature #2531 (In Progress): LocalControlHeader
-
10:15 AM
Feature #2531: LocalControlHeader
- Sounds good. Since this is a low-use feature, there won't be a problem to change to a new approach at some point when...
03/02/2015
-
- Throwing the error was just my suggestion, not requirement.
I'm +1 with having only Transport.isLocal(), which o... -
- The application could know a priori: it COULD duplicate the logic in the Face constructor to know what type of Transp...
-
- No. I'm not suggesting adding anything to Face interface.
Without initiating connection (=not knowing IP), you can... -
- Are you suggesting #2 from note #29? Then I have to be connected to check if the transport is local and those two thi...
-
- Actually, the implementation of this doesn't really depend on ConnectionInfo. Transport.isLocal can throw when trans...
-
- My opinion about ConnectionInfo concept is recorded as part of issue #2571
-
- I like it. No Face.isLocal(), just Transport.isLocal().
The problem now lies in the implementation. The only objec... -
- What about a slightly different way. I'm kind of considering what you want to do as a special case (therefore my sug...
-
- I agree with all of the points about abstraction. What I need is some way to know if I am connected to a local NFD or...
-
- I would still argue that these are unnecessary details that need to be handled by face itself.
I can only be sayin... -
- See #23... multiple modules accessing the same face and they want to know if it is local or not (they don't need/want...
-
- I wonder for the reason you would like to do it?
-
- Alex Afanasyev wrote:
> I'm thinking primarily about the use case. If the only use case (and should be in my opin... -
- Just a few missing details. Construction of Transport instance allow recording parameters necessary for this instance.
02/26/2015
-
- The callback interface should be a different discussion. I personally do not like that the callback is forced receiv...
-
08:38 AM
Task #2579: Provide send/sendData in Face() and deprecate in Transport
- Hi Jeff,
Right now, the OnInterest callback passes a Transport to the application so it can give it the data packe...
02/25/2015
-
- I think what you mentioned is not semantics, rather side effects, though not sure. May be it should be just "make d...
-
- Just so I am clear: What are the exact semantics requested of the library / forwarder by this call? ("Send" to the f...
-
- This should not be "send", as semantically we are not sending anything, rather make data available if it is requested...
-
- send/sendData are most appropriately associated with Face. App should not need to use Transport object in typical si...
-
- Signature classes do not need to be virtual or have virtual methods. I'm simply proposing to re-implement the design...
-
- NFD RIB Management protocol defines two of the flags that exist in ForwardingFlags, but it should be implemented some...
-
- Current implementation, does not follow the semantics of NDN packet format, where by default interests request any da...
-
- Public API should not use method names such as "setInterestLiftimeMilliseconds". Instead, time duration should be ca...
-
-
- Boolean MustBeFresh should be used explicitly.
-
-
- Exclude filter abstraction should provide a convenient interface to work with the exclude filter, not just container ...
-
-
- Although I agree with some semantical issues with `Face.put(Data)` method, it is necessary as Face should be the only...
-
- While it is only possible to register a prefix with local NFD, the callback dispatch inside the Face can use a more p...
-
- There should be at least two forms of this method:
// atomic set interest filter (only internal face dispatch)... -
- Jeff Thompson wrote:
> > Actually... is it clearer?
>
> If you don't like how that looks, then I'd be happy if ... -
- Think of this use case: one module in your application creates a face and sets it up with security, etc. It then pass...
-
04:02 PM
Feature #2532: Remote Prefix Registration
- > Actually... is it clearer?
If you don't like how that looks, then I'd be happy if you added an equals() method t... -
- I'm thinking primarily about the use case. If the only use case (and should be in my opinion) to check isLocal after...
-
- Alex, but the Transport can still know if its local or not without being connected, right?
-
- Actually... is it clearer?
```
if(connectionInfo_ == null || !((ConnectionInfo) connectionInfo).getHost()
... -
- I would thrown an exception in isLocal when transport is not connected.
-
- Sounds good to me. That check is comparing whether the references are the same, which they should be if ConnectionInf...
-
03:46 PM
Feature #2532: Remote Prefix Registration
- In TcpTransport.isLocal, you check "connectionInfo != connectionInfo_":
https://github.com/named-data/jndn/blo... -
- No, Jeff and I had talked about actually connecting the transport when isLocal() is called but I don't think that is ...
-
- The use prefix registration is only possible after Face is actually connected to the remote end = DNS resolution is a...
-
- Ok, take a look at the current state:
- isLocal() exposed on Face, https://github.com/named-data/jndn/pull/6/file... -
02:32 PM
Feature #2532: Remote Prefix Registration
- Yes, we can assume that ConnectionInfo will not change because it is the one defined by TcpTransport which doesn't ch...
-
- Yes, I'm having trouble figuring out the best way to do that, though. Because Node is the only one maintaining a refe...
-
01:36 PM
Feature #2532: Remote Prefix Registration
- Hi Andrew. If TcpTransport.isLocal can do a costly DNS lookup, should it cache the result for the next call to regist...
-
- Updated UDP transport accordingly, see PR at https://github.com/named-data/jndn/pull/6. Like we talked about on Skype...
-
- Got it. It was just a little unclear what you meant by registering prefixes. Now I understand that you want to regis...
-
- Alex, I am no expert on the LocalControlHeader feature but from what Junxiao explained to me at the retreat I think I...
-
- Andrew, I'm a little bit confused how the need of creating routes depends on LocalControlHeader. This header is desi...
02/24/2015
-
- I have no other place to comment on the code. Udp face is never considered local, so udp transport's isLocal() can/s...
-
- I'm convinced. I initially wanted to hide the localhost/localhop complexity but not being able to explicitly choose c...
-
03:12 PM
Feature #2532: Remote Prefix Registration
- I like the idea of a separate Face method to do remote prefix registration because it is not just a matter of changin...
-
- Alex and Jeff, take a look at this revision and associated integration test. In the integration-tests directory, run ...
-
- I'm not saying that the remote registration function is not useful. I was just thinking that switch between remote a...
-
- Clearer discussion at http://redmine.named-data.net/issues/2451
02/21/2015
-
- What do you mean by non-standard? If the NFD provides a feature that allows remote registration, why shouldn't my app...
-
- For me, this use of remote registration is non-standard and I wouldn't add mechanics to automatically handle it. My...
-
- I tested with NFD v0.3 and the /localhop/nfd/rib/register works as expected (the prerequisites are setting command si...
02/19/2015
-
09:52 AM
Task #2543 (Closed): Port SegmentFetcher
- Port SegmentFetcher from ndn-cxx. (Also in PyNDN, NDN-JS and jNDN.) CompleteCallback should provide a Blob. Internall...
-
- Sounds good to me; that's all I need right now to do what I need to do.
02/18/2015
-
04:46 PM
Feature #2531: LocalControlHeader
- For starters, I'd suggest supporting a "set" for local control headers in the outgoing interest and a "get" for the i...
02/17/2015
-
- My application needs the ability to register prefixes from a node that does not have a local NFD. The current release...
-
- From within my application, I need to programmatically create routes on the NFD and I want to create routes back to o...
Also available in: Atom