Too many time, I've woken up too late only to discover I'm a
stakeholder... :-)

So, I know it's not directly helpful now, but I'm sure you'll keep it
mind when the time comes.

About debugging stripped images - I don't think a back and forth "do you
support Object>>printString?" is the simplest way to go. I'd suggest two
strategies:
1. Define a minimal protocol that's needed. If you need to debug your
stripped applications, make sure you leave those in.
2. Install at run time a debugging extension that ensured to not
conflict with existing methods (call your methods #rdbgPrintString and
so forth). This might require that you create locally compiled methods
for a class that exists only remotely, but it leaves the complexity
bounded, and it really shrinks the protocol you treat as critical (see
1).

The nice part is both parts of this strategy can be executed very
lazily, as the remote targets shrink. 

Just an idea...

Daniel

Jon Hylands <jon at huv.com> wrote:
> Daniel,
> 
> This is an interesting concern. I plan to have everything that happens in a
> remote debugger/browser happen remotely. Having an option to log a copy of
> the change log locally is probably a good thing as well, as is building up
> a local change set (or something like a change set) with those changes.
> 
> One thing that will be interesting is debugging stripped images. The tool
> will need to query the remote system to find out if a particular operation
> is still supported, or (more likely) it will protect all execution with a
> good exception handler (which we want anyways).
> 
> Anyways, I've got a bit of work to do before I have to worry about this
> stuff...
> 
> Later,
> Jon
> 
> --------------------------------------------------------------
>    Jon Hylands      Jon at huv.com      http://www.huv.com/jon
> 
>   Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
>            http://www.huv.com