RE: [cdt-dev] [DSF] SessionType

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Vladimir Prus [mailto:vladimir@xxxxxxxxxxxxxxxx] 
> Sent: Thursday, July 08, 2010 3:26 PM
> To: Marc Khouzam
> Cc: 'cdt-dev@xxxxxxxxxxx'
> Subject: Re: [cdt-dev] [DSF] SessionType
> 
> On Thursday 08 July 2010 21:46:26 Marc Khouzam wrote:
> 
> > 
> > > -----Original Message-----
> > > From: Vladimir Prus [mailto:vladimir@xxxxxxxxxxxxxxxx] 
> > > Sent: Thursday, July 08, 2010 12:39 PM
> > > To: cdt-dev@xxxxxxxxxxx
> > > Cc: Marc Khouzam
> > > Subject: Re: [cdt-dev] [DSF] SessionType
> > > 
> > > On Thursday 08 July 2010 19:48:59 Marc Khouzam wrote:
> > > 
> > > > > -----Original Message-----
> > > > > From: cdt-dev-bounces@xxxxxxxxxxx 
> > > > > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of 
> Vladimir Prus
> > > > > Sent: Thursday, July 08, 2010 6:17 AM
> > > > > To: cdt-dev@xxxxxxxxxxx
> > > > > Subject: [cdt-dev] [DSF] SessionType
> > > > > 
> > > > > 
> > > > > Hi,
> > > > > I'm looking at this definition from DSF:
> > > > > 
> > > > > 	public enum SessionType { LOCAL, REMOTE, CORE }
> > > > 
> > > > This is DSF-GDB specific.  (just to be fair to DSF :-))
> > > > 
> > > > > Unfortunately, despite quite some years of experience 
> > > with gdb, I have
> > > > > no idea what LOCAL and REMOTE means. 
> > > > 
> > > > REMOTE is when we connect to a gdbserver.
> > > > LOCAL is when we use GDB on the host only.
> > > 
> > > And what if we connect to something that speaks gdb protocol, 
> > > but is not a gdbserver?
> > 
> > Sure, but when I wrote this class, it was focused on the 
> > functionality of DSF-GDB, which only supports gdbserver.
> > 
> > > > > Would it not be better to remove session type 
> completely, and use
> > > > > more detailed switches, like 'should run or continue 
> to be used
> > > > > when starting program', or 'run can be used to restart'.
> > > > 
> > > > If the problem is using -exec-run or -exec-continue, then the
> > > > service which dispatches those commands can be 
> overridden to handle
> > > > the cases you want to deal with.
> > > 
> > > I am becoming somewhat concerned :-( You seem to suggest that
> > > overridding a service -- that is, writing my own service class
> > > and doing what I want -- is a sensible approach.
> > 
> > Yes.  That's DSF.
> > 
> > > However,
> > > suppose I want to go this route. I'll derive from GDBControl_7_0
> > 
> > You don't even have to do that.  You can create your own service
> > altogether.
> 
> Copy-pasting everything from GDBControl_7_0?

It has advantages.  We did that a couple of times in
DSF-GDB (e.g., GDBProcesses_7_0).  The value is if GDBProcesses is
changed, we don't have to re-test with GDB 7.0.  But I have to admit
that we have moved away from that approach now that our classes are
more stable.  I was just being complete :-)

> > > and what is the next step? startOrRestart method is pretty big,
> > > and all I want to do is modify a single if condition inside it.
> > > Clearly, copy-pasting it is not a good approach 
> > 
> > Yes, no one likes copy-pasting, but at some point it is
> > unavoidable.  Your case requires to modify a single if condition,
> > while someone else may need to modify some other tiny part
> > of the same method.  At some point, we can't make every little
> > behavior customizable.
> 
> I'd say there must be some balance here. Of course, it's not 
> possible to
> have every if statement become a method call. However, there 
> are surely
> some aspects that commonly need to be customized, and it 
> seems reasonable
> to provide extension interfaces how derived classes can 
> customize them.

Yes.  One can override startOrRestart() right now.
I guess the granularity of startOrRestart() is to high :-)

> Are there so many such methods in GDBControl_7_0 that it 
> makes sense to refuse
> further additions, or you thin that -exec-run/-exec-continue 
> difference is
> not common enough?

I'd accept everything if it wasn't for API compatibility :-)
Adding a new API is usually ok, but the problem is when we want to
add it to an existing interface: anyone using that interface
will break.

It seems the -exec-run/continue is a valid point since it is
already bothering multiple integrators.  If we do it without
breaking the API, it will be fine with me.  If we decide
to break the API for other reasons later on in the Indigo release,
we can revisit the solution and make it simpler if you prefer.

We can discuss the details of how to avoid breaking the API
in the bug you wrote.

> Note that I'm not even asking about this specific method, but I wanted
> to understand general design guidelines, and hope they are 
> more detailed
> that "create a custom service by copy-pasting".

The more stuff contributed to DSF-GDB the better.  So I'm open
to any changes that would help.
But we have to avoid API breakage and also unnecessary new APIs
that we'll have to maintain 'forever'.

So, let's get the -exec-run/continue fix in, using a backwards
compatible solution.

Marc