I also vote in 1) On Thu, Dec 18, 2008 at 3:35 PM, Stuart McCulloch <[email protected]> wrote: > 2008/12/18 Richard S. Hall <[email protected]> > >> Stuart McCulloch wrote: >> >>> 2008/12/18 Jon Brisbin <[email protected]> >>> >>> >>>> On Dec 18, 2008, at 8:07 AM, Richard S. Hall wrote: >>>> >>>> I guess the question is, do people think it would be worth it? >>>> I'm deploying in a server environment, so this was written with a >>>> ServiceMix-like environment in mind. I can confirm that, for me, it is >>>> hugely beneficial and time-saving. I can use all the keyboard shortcuts >>>> I'm >>>> used to (CTL-A/E/D/K) and the history support across restarts is >>>> extremely >>>> helpful. >>>> >>> >>> sounds good to me, I think we should offer a JLine version of the shell as >>> it does make the user experience a lot better >>> >>> perhaps we could adapt the simple shell to check for some sort of JLine >>> extension bundle at startup, and then fall back to the current behaviour >>> if >>> no extension is found? >>> >> >> Yes, that would be another approach. Is it feasible? Also, does it even >> make sense given the braindead simpleness of shell.tui? >> >> It seems there are three options: >> >> 1. Merge with shell.tui and implement some sort of fallback for >> platforms where JLine doesn't work. >> 2. Create a separate shell.jline bundle. >> 3. Modify shell.tui to be extensible in some way and create a >> shell.jline bundle using this extension mechanism. >> >> Any opinions on which approach might make the most sense? >> >> If we followed (1), it would become the new default shell UI for Felix by >> definition. If we follow (2) or (3), then we'd still need to decide if is >> should be the default shell UI. >> > > true, and 1) also means you only have one bundle to deal with - I think it > makes sense as long as no-one objects to the extra Kb > > so +1 from me for adding JLine support to the current TUI shell > > Part of me leans toward (1) since we already have enough subprojects that >> releasing them all is becoming time consuming. Further, I would guess that >> really small devices are typically not going to want a textual UI. Also, it >> is just nice not to have to mess with having to choose which bundles to >> deploy. However, I also see the benefits of not merging. So, it is somewhat >> of a toss up. >> >> -> richard >> >> FWIW I was really ready to go to ServiceMix kernel for the shell. I liked >>> >>> >>>> the way the app deployed in stock Felix better (much less memory use), >>>> but >>>> the development cycle I've found my self in--NetBeans/Maven...compile, >>>> then >>>> do an update 42--makes working with a readline-like shell a lot more >>>> productive. I'm back and forth between NB and the shell a lot. Using >>>> stock >>>> Felix, there's no auto-reload like using some other fancy-pants server >>>> environments like dm Server or ServiceMix. :) >>>> >>>> >>>> >>> >>> if you install the FileInstall bundle ( >>> http://felix.apache.org/site/apache-felix-file-install.html) you can get >>> basic auto-updates :) >>> >>> I don't know what the implications are for non-server, non-desktop >>> >>> >>>> applications, but it's interesting that someone else was thinking along >>>> the >>>> same lines I was (great minds and all, right? ;). >>>> >>>> >>>> >>>>> Of course, there is also another possibility, which is to not to merge >>>>> it, >>>>> but create a separate shell UI bundle. >>>>> >>>>> >>>>> >>>> This would be the best solution, IMHO. This would give the developer a >>>> choice of the more portable basic UI or a more developer-friendly one. >>>> I'm >>>> probably going to turn the shell off entirely in production, so which >>>> bundle >>>> the shell is in doesn't really matter much (whether the existing TUI one >>>> or >>>> a new JLINEUI one). I was mainly interested in development-time >>>> productivity. >>>> >>>> Thanks! >>>> >>>> Jon Brisibn >>>> http://jbrisbin.com >>>> >>>> >>>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Cheers, Stuart >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
