Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Mark Wielaard <mark@klomp.org>]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

Hi Andrew,

On Thu, 2007-06-14 at 09:59 -0400, Andrew Cagney wrote:
> Good questions.  The key difference is that a dead system has no state 
> (well, ok, only one) where as a live system is statefull and 
> consequently, a dead system has no reason to implement or handle 
> abstract methods such as sendrecContinue et.al where as a live system 
> does.

Yes, but those are implementation details. Not differences in public
interface are they?

>   Over time we'll accumulate other "live" hosts - utrace, remote, 
> and then when we've a problem, we'll with new information available, 
> likely review how to better break down the "live" case.

Yes, but my point is more that pre-mature refactoring at this point
seems not a good idea. We don't seem to have all the information yet.
But maybe you do have a clear picture already. I am trying to get an
idea what we would really gain from it at this point. Which api users do
you have in mind and what are they doing now through frysk.proc (or
directly through frysk.proc.ptrace and frsyk.proc.core) that would be
better modeled through the proposed properties-based package
abstractions?

> This further refinement, and introduction of frysk.proc.live.LiveTask 
> lets us finish the refactoring task I started of separating out specific 
> implementations of a Host (corefile, ptrace) from the abstract model.  
> For instance, those state variables in frysk.proc.Task and corresponding 
> methods can be localized to frysk.proc.live.

Are you sure they are "live"-properties and not just implementation
details of the ptrace-implementation? Can you give a list of variables
and methods you think aren't just ptrace implementation details, but are
properties of a LiveTask?

My main concern here is that we are abstracting cases for which there is
just one implementation at this point (or rather, just renaming the
specific implementations as if they are abstract properties) and that we
are better of waiting till we actually have multiple implementations
with shared properties to see how a properties based setup based on live
or dead looks like.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]