Re: [exec] vision for the library

[Brett Porter <br...@apache.org>]

jerome lacoste wrote:
> [Sorry for the long mail. I hope I was clear enough this time]

Crystal. Just took 4 months to read :)

> Current commons-exec features
> --------------------------------------------
> 
> It
> - starts commands in the various platforms and SDK. Todays that's the
> launcher package. It's mostly good as is.
> - retrieves os environment, determining on which os we are, etc..
> Today that's the OS class + environment package.
> - builds a process (that's part of Execute)
> - attaches stream and process operations around the execution of a
> Process (still part of Execute).
> - tries to provide good defaults for executing a process (hides
> complexity of the Execute) (What Exec does today).
> - should allow clients to make their own stream operations
> (redirection, visitor-like patterns for consuming information,
> etc...). Today exists but not that reusable.

This should be helpful in sketching some API interfaces.

> Commons-exec becomes a sort of (ProcessBuilder + advanced features) on
> all SDK, all platforms.
> 
> Proposed architecture
> - Launchers: exist as today
> - OS functionality
> - ProcessLauncher, (our ProcessBuilder)
> - Execute (or Executor?): Flexible, we use it to tie together the
> various concepts in the execute() call (stream management, process
> management, process building, etc...)
> - Exec (or ??) makes it easy to use Execute/or.

I'm missing the difference between Exec and Executor - but otherwise agree.

> The architecture doesn't need to be very different from what it is today.
> In fact I think it can be achieved by refactoring the current code. I like that.

I'd like to have some clean interfaces even if they are similar.

I think we should use interfaces with an implementation so we can later
do what Dion suggested at one point - a "remote exec" implementation.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [exec] vision for the library

[jerome lacoste <je...@gmail.com>]

On 1/24/06, Brett Porter <br...@apache.org> wrote:
> jerome lacoste wrote:
> I'm big on interfaces for defining and maintaining a simple public
> contract of the API,

They help to some extent, but if you are going to use interface just
to define your public contract, I think it might be an overuse.

An 'implicit' interface is sometimes enough.

[...]

> However, this situation would have to be worked around by adding to the
> factory instead of replacing.
>
> WDYT?

Factories have their use, e.g. when you want to keep control on the
returned objects, when you can do smart stuff inside the factory to
return the more appropriate object and make the client life simpler,
etc.

I think that today, full fledged dependency injection fits better than
this 'old school' IoC pattern. In particular a factory added without
real good reasons could limit the client dependening on possibilities.

I've seen people go from one class to one class + its interface + one
factory [+ the factory interface + ...]. I did that mistake before,
and I found out it didn't bring me that much benefits. I am trying to
avoid it now.

WRT intefaces, I am OK to use one, if it is minimal and has a good use
case. In fact if there's no need to have an interface right now, it
can always be added afterwards. Same for the factory.

In our case, an interface should be minimal. As you said in another
post getters and setters sshould not be part of the interface.

Basically, we only need something like:

Process start() [throws ExecuteException];

But we can add that later on, if needed. So let's design the thing as
simple as possible and to grow from there. WDYT?

Jerome

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [exec] vision for the library

[Brett Porter <br...@apache.org>]

jerome lacoste wrote:
> Exec was deemed to be an object that makes it easy to use the Executor
> for simple use cases, while Executor was more flexible.

Ok. The names could be better :)

> I'd rather have implementations then we add an interface in a later
> version if we need a remote exec.
> 
> Jerome, trying to use less interfaces

:)

I'm big on interfaces for defining and maintaining a simple public
contract of the API, especially when there is already a proposed use
case. I think adding it later would mean weakening return types in some
instances that would break existing code, limiting the ability to do
that, eg:

class Exec {
}

class ExecFactory {
  Exec getExec();
}

...

Exec exec = execFactory.getExec();

would become:

interface Exec {
}

class Exec implements ExecInterface {
}

class ExecFactory {
  ExecInterface getExec();
}

...

Exec exec = execFactory.getExec(); // needs an explicit cast to compile

It's not a great example or naming, I know.

However, this situation would have to be worked around by adding to the
factory instead of replacing.

WDYT?

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [exec] vision for the library

[jerome lacoste <je...@gmail.com>]

> > Proposed architecture
> > - Launchers: exist as today
> > - OS functionality
> > - ProcessLauncher, (our ProcessBuilder)
> > - Execute (or Executor?): Flexible, we use it to tie together the
> > various concepts in the execute() call (stream management, process
> > management, process building, etc...)
> > - Exec (or ??) makes it easy to use Execute/or.
>
> I'm missing the difference between Exec and Executor - but otherwise agree.

Exec was deemed to be an object that makes it easy to use the Executor
for simple use cases, while Executor was more flexible.

>
> > The architecture doesn't need to be very different from what it is today.
> > In fact I think it can be achieved by refactoring the current code. I like that.
>
> I'd like to have some clean interfaces even if they are similar.
>
> I think we should use interfaces with an implementation so we can later
> do what Dion suggested at one point - a "remote exec" implementation.

I'd rather have implementations then we add an interface in a later
version if we need a remote exec.

Jerome, trying to use less interfaces

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org