Activity
From 02/01/2015 to 03/02/2015
03/02/2015
-
03:27 PM Feature #2532: Remote Prefix Registration
- Throwing the error was just my suggestion, not requirement.
I'm +1 with having only Transport.isLocal(), which o... -
02:44 PM Feature #2532: Remote Prefix Registration
- 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...
-
07:16 PM Task #2579: Provide send/sendData in Face() and deprecate in Transport
- 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