felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: I implemented a JLine-based TUI for Felix
Date Thu, 18 Dec 2008 15:11:28 GMT
Stuart McCulloch wrote:
> 2008/12/18 Jon Brisbin <jon.brisbin@gmail.com>
>> 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.

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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message