Community
Participate
Working Groups
I would like to rename the fields and methods based on the name 'usingRemotePeers' to 'useLocalPeerOnly'. The latter is more accurate. It properly reflects that the delegate can be told to either (a) use only a local peer, or (b) use any peer (local or remote). 'usingRemotePeers' is misleading; it implies the delegate should only use a remote peer, which is not the case. Additionally, it being plural also misrepresents the launcher as using more than one peer. It only deals with a single peer (see getTCFPeer method)
+1. This is what I get for writing code on the flight back from EclipseCon. It also reflects the tcf local vs. remote peer confusion.
(In reply to comment #1) > It also reflects the tcf local vs. remote peer confusion. I opened bug 317636 to get Eugene to mitigate that :-)
(In reply to comment #1) > +1. This is what I get for writing code on the flight back from EclipseCon. It > also reflects the tcf local vs. remote peer confusion. Looking more closely at the implementation, it occurs to me that your intention was to differentiate between a peer running on 'this' machine vs one running on 'another' machine, since the check you do is based on the peer's IP address. That being the case, we need to avoid using the terms 'local peer' and 'remote peer', since indeed those concepts mean something else in TCF. So, I'd like to rename the field/methods 'usePeerOnThisMachineOnly'. A bit wordy, but oh well. What do you think?
That sounds OK. I was really trying to simplify the case (as in the Windows or Linux debuggers) where you can predict that the agent is running on the same system and avoid looking at peers you find on the sub net.
(In reply to comment #4) > That sounds OK. I was really trying to simplify the case (as in the Windows or > Linux debuggers) where you can predict that the agent is running on the same > system and avoid looking at peers you find on the sub net. That's a reasonable use case. We just need to avoid the terms "local" and "remote" peers.
(In reply to comment #5) Found a better naming approach: keep to the terms local agent and remote agent. An agent is basically code running on a machine. It's either running locally or somewhere else. A remote *peer* can be running in a local agent or a remote one. The term 'remote' when applied to peer is relative to a specific TCF agent, and there can be multiple agents on a host. Anyway, the changes are in a patch in bug 317601
(this is part of a batch change) The Eclipse CDT EDC (https://wiki.eclipse.org/CDT/cdt-debug-edc) is now obsolete and has not had any active development since 2011. Therefore the still open bugs are being marked as wontfix. The git repo for the project still exists for posterity at https://git.eclipse.org/c/cdt/org.eclipse.cdt.edc.git/
