That's the right way to do. Shell UI is responsible for user interaction and completion of commands and parameters.
Where can I download early draft of R4.2 . Stevens On Wed, Jan 7, 2009 at 4:08 PM, Richard S. Hall <[email protected]>wrote: > Sounds nice. You should check out RFC 132 in the R4.2 early draft to get > some ideas about the direction of the potential shell. > > -> richard > > > > Stevens Gestin wrote: > >> Hi, >> >> it seems quiet a good news that replacement of current shell API is on >> rail. >> >> Of course you are right to mentions that shell API must not deal with UI >> functionalities. It's completly two different things. You have the shell >> engine which execute commands and the UI engine which is responsible for >> completion and interaction with users. >> >> In our implementation, commands can read through a stdin. Chaining >> commands >> links stdout of command N to stdin of command N+1. Interaction with user >> through the first stdin is done with a UI Shell service. >> >> I also implements a very simple formula engine which allow us to set a >> variable like this: >> webserver.port = {clientserver.port} + 1 >> or >> webserver.root = {install.directory} + "\components\webserver\war" >> >> This allow us to simplify configuration of our application. >> >> In our server, we use the shell service as the core component. We interact >> with the OSGI services through the shell service. This simplify >> considerably >> configuration of Felix startup. >> >> We can record scripts and re-excute them later. >> >> Best Regards, >> Stevens >> >> >> On Wed, Dec 31, 2008 at 5:25 PM, Richard S. Hall <[email protected] >> >wrote: >> >> >> >>> The shell API is very, very simple (and simplistic). It was never >>> intended >>> to be a thing of beauty. It has been around for 6 or 7 years purely as a >>> simple means of interacting with the running framework. It was never >>> intended to be a killer app for Felix. >>> >>> However, I am not against improving it or even completely replacing it. >>> The >>> main thing I have thought about improving is allowing commands to have a >>> stdin so they can be more interactive. But we have to remember that it >>> would >>> be nice for the shell to remain reasonably lightweight and compatible >>> with >>> different Java platforms. >>> >>> There is actually some work within the OSGi Alliance to move toward a >>> standard shell and we may be involved in that...I don't have more details >>> on >>> it yet, but it is part of RFC 132 from the early spec draft. >>> >>> So, this area is looking like it could change before long. >>> >>> -> richard >>> >>> p.s. There is a difference between command API and things like command >>> completion and history. The former deals with core capabilities, while >>> the >>> latter deals with UI issues. The core shouldn't assume a UI. Sometimes it >>> seems that people lump these two together. >>> >>> Stevens Gestin wrote: >>> >>> >>> >>>> Hi, >>>> I've already sent an email concerning limitation of Command interface >>>> few >>>> months ago. I totally developted a shell engine from scratch. >>>> >>>> My shell is registering in OSGI container as a service. Other services >>>> register ShellExtension. Registration of extension initiate an update >>>> process on the shell service. Shell extension provides a simple >>>> interface >>>> which allow retrieval of extension commands. Each command provides >>>> information like short help, complete help, description and version. >>>> >>>> You can chain commands, use variables (in global shell context or >>>> session >>>> context). It supports short and long option (- and -- flags), >>>> whitespaces >>>> and some other features. >>>> >>>> Best Regards, >>>> Stevens >>>> >>>> >>>> >>>> >>>> On Wed, Dec 31, 2008 at 1:02 PM, Trejkaz <[email protected]> wrote: >>>> >>>> >>>> >>>> >>>> >>>>> The Command API is currently... >>>>> >>>>> public void execute(String command, PrintStream out, PrintStream err) >>>>> >>>>> After having written a few commands, I find myself doing two things a >>>>> lot. >>>>> >>>>> Firstly, I find myself parsing command-lines. >>>>> >>>>> Currently all my parameters are whitespace-free but that's about to >>>>> change. So now I need a full parser which handles quotes in a >>>>> sensible fashion consistent with my other commands, and indeed Felix's >>>>> existing commands. >>>>> >>>>> It seems like the ultimate solution to this part would have been to >>>>> pass the command as a String[] instead of the raw command. Obviously >>>>> I can write my own convenience API for this, but I started wondering >>>>> if Felix is already hiding something like this..? >>>>> >>>>> Secondly, I find myself wondering how to handle sub-commands. And >>>>> this is where the mail gets big. Sorry about that. for tl;dr types, >>>>> scroll down to my proposed interfaces and points below those. >>>>> >>>>> Effectively having solved the parser problem already (which I haven't >>>>> solved correctly actually, but for the sake of discussion - the real >>>>> code splits on \s+) I now find myself implementing my own sub-command >>>>> framework. >>>>> >>>>> Main problems: >>>>> >>>>> * For getUsage() to contain a full description of what my top-level >>>>> command can do, it takes multiple lines. But Felix then shows the >>>>> whole thing from the help command. >>>>> * Putting all the commands as methods on one class starts to become >>>>> unmanageable and then you create a sub-command API, and: >>>>> * The API for sub-commands looks awfully similar to the API for >>>>> commands. >>>>> >>>>> Possible resolution: >>>>> >>>>> In my case I went with the main command parsing its first argument and >>>>> then switching to different methods. >>>>> >>>>> I started wondering if there was a "proper" way to do this, and on >>>>> investigation I see other commands doing this all themselves too, like >>>>> "obr help". Why not invert it? Can't "help" show obr in the list >>>>> with a getShortUsage(), and then "help obr" shows the list of >>>>> sub-commands? You could almost allow getName() to contain spaces and >>>>> then improve the shell to do better matching. Or you could have an >>>>> explicit API for getting the sub-commands for a given command, and >>>>> then each one can have shortUsage and fullUsage. >>>>> >>>>> I don't want to turn this into a "let's design a Command API" >>>>> discussion, but _if_ I were writing a new command API from scratch, I >>>>> guess ideally I would like to see this bare minimum: >>>>> >>>>> public interface Command { >>>>> >>>>> // If a top-level service comment then this needs to be unique >>>>> in the shell service. >>>>> String getName(); >>>>> >>>>> // "help" or "help obr" would show these: >>>>> String getShortUsage(); >>>>> String getShortDescription(); >>>>> >>>>> // "help obr list" would show these: >>>>> String getFullUsage(); >>>>> String getFullDescription(); >>>>> >>>>> /** >>>>> * Executes a command. >>>>> * >>>>> * @param context the context in which the command is being >>>>> run. All parameters passed through here. >>>>> */ >>>>> public void execute(CommandContext context); >>>>> >>>>> /** >>>>> * Gets all sub-commands. These are commands where {...@link >>>>> #getName()} >>>>> * would return the name of the sub-command, >>>>> */ >>>>> Command[] getSubCommands(); >>>>> } >>>>> >>>>> public interface CommandContext { >>>>> String getCommandLine(); >>>>> String[] getCommand(); >>>>> PrintStream getErrorStream(); >>>>> PrintStream getOutputStream(); >>>>> } >>>>> >>>>> Good points: >>>>> * You can extend the context later without disrupting the API >>>>> >>>>> Deficiencies: >>>>> * On the other hand extending the *context* isn't possible. Commons >>>>> Chain solves this for their command model by going all out and just >>>>> putting a map in there, which is possibly too much. (And well, >>>>> they're not a shell either. So you would have to pass out and err >>>>> streams as parameters too, to actually use that.) >>>>> * Still passes the full command in the parameters. Purists would say >>>>> this is pointless and that it would be more reusable if it only passed >>>>> the parameters, which would make it possible to change the location of >>>>> commands in the tree without rewriting the command. >>>>> >>>>> But... why develop a brand new command API? There are already two >>>>> good ones out there which I'm aware of... >>>>> >>>>> 1. GShell's Command API - GShell is also in itself a good shell too, >>>>> with proper autocompletion for commands, and this is exposed >>>>> throughout the API as well. >>>>> >>>>> 2. JNode's Command API - I have seen people tout JNode's as being >>>>> better than GShell... but it is LGPL but JNode have never really >>>>> advertised their code base as a collection of reusable components. >>>>> >>>>> Both of these are trying to solve the same problem of making a generic >>>>> API where commands, help, completion and everything are considered. I >>>>> would say JNode's is marginally better because if its notion of >>>>> argument types. >>>>> >>>>> I guess what I'm wondering is, was there a particular reason Felix's >>>>> is the way it is, or is it because the codebase was pull in from >>>>> wherever and nobody has really used it intensively yet? >>>>> >>>>> >>>>> TX >>>>> >>>>> P.S. And on a side-note... I have been wondering how to get >>>>> user-level access control for commands, to control who can do what. >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Le respect commence par celui de l'environnement
