ExecutionApiMerge

(Difference between revisions)
(Execution API merge)
(Execution API merge)
Line 13: Line 13:
* it is ssh-oriented. It's fundamental API object, ExecutionEnvironment, doesn't provide a way for specifying a way of accessing remote host
* it is ssh-oriented. It's fundamental API object, ExecutionEnvironment, doesn't provide a way for specifying a way of accessing remote host
* it's error-handling/flow is not well structured and not always clear
* it's error-handling/flow is not well structured and not always clear
 +
 +
cleaned-up dlight.nativeexecution can be used as an implementation module with extexecution API, but extexecution should be extended in this case to support features proposed by the dlight.nativeexecution.
 +
 +
==Scope ot the review==
 +
* I would like to review an API (cleaned-up) of nativeexecution (not binded anyhow to extexecution) with the main aim to demostrate
 +
** what functionality this module provides (all this functionality was needed for CND's remote support)
 +
** how the functionality affected some API design decisions
 +
* Then I would like to make conclusions on what is missing in the extexecution (mostly this is about ExternalProcessBuilder), how it could be extended in a compatible way to make it possible for users to use full range of functionality provided by nativeexecution.

Revision as of 11:26, 5 November 2012

Execution API merge

Contents

Problem statement

  • There is a need of common public API for executing external processes - either on local host or remote host.
  • There are several flavors of related APIs:
    • dlight.nativeexecution - non public (friend) API used by C/C++ modules and many modules in Studio ( 119 friends in total); All the code that uses this API is under our control;
    • extexecution - PUBLIC API for executing remote processes. It is plug-able and allows to pass own ProcessBuilder. As API is public, there are users of the API that are not under our control... (54 modules in nb codebase use it)
    • richexecution (within lib.terminalemulator)

dlight.nativeexecution is intensively used in CND. This module provides functionality for runnig processes on different platforms (*nix, windows, macos), it deals with processes starting/terminating, I/O, different terminals, signals, and so on. So it provides good functionality coverage, but has several big problems:

  • nowadays it requires serious cleanup;
  • it's implementation has many places where call to some method initiates a connection, which is unexpected in most cases
  • it is ssh-oriented. It's fundamental API object, ExecutionEnvironment, doesn't provide a way for specifying a way of accessing remote host
  • it's error-handling/flow is not well structured and not always clear

cleaned-up dlight.nativeexecution can be used as an implementation module with extexecution API, but extexecution should be extended in this case to support features proposed by the dlight.nativeexecution.

Scope ot the review

  • I would like to review an API (cleaned-up) of nativeexecution (not binded anyhow to extexecution) with the main aim to demostrate
    • what functionality this module provides (all this functionality was needed for CND's remote support)
    • how the functionality affected some API design decisions
  • Then I would like to make conclusions on what is missing in the extexecution (mostly this is about ExternalProcessBuilder), how it could be extended in a compatible way to make it possible for users to use full range of functionality provided by nativeexecution.
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo