Activity
From 02/04/2015 to 03/05/2015
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...
-
03:47 PM Task #2543: Port SegmentFetcher
- 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
-
11:05 PM Feature #2570: Refactoring of Exclude public interface
- +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