Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 317640

Summary:	isUsingRemotePeers in AbstractFinalLaunchSequence is confusing
Product:	[Tools] CDT	Reporter:	John Cortell <john.cortell>
Component:	cdt-debug-edc	Assignee:	Ken Ryall <ken.ryall>
Status:	RESOLVED WONTFIX	QA Contact:	Ken Ryall <ken.ryall>
Severity:	normal
Priority:	P3
Version:	7.0
Target Milestone:	8.0
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description John Cortell

2010-06-22 16:24:34 EDT

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)

Comment 1 Ken Ryall

2010-06-22 17:03:16 EDT

+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.

Comment 2 John Cortell

2010-06-22 17:30:47 EDT

(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 :-)

Comment 3 John Cortell

2010-06-22 17:48:14 EDT

(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?

Comment 4 Ken Ryall

2010-06-22 18:03:32 EDT

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.

Comment 5 John Cortell

2010-06-22 18:23:54 EDT

(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.

Comment 6 John Cortell

2010-06-24 18:05:36 EDT

(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

Comment 7 Jonah Graham

2019-12-30 18:39:27 EST

(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/