[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rhc shell



On Wed, 26 Dec 2012, Clayton Coleman wrote:

> When we have access tokens pretty much all the pain goes away.  I've got access tokens running in a model refactor branch now, and most of the client refactors we'll need done as well.
>
> Startup load time is mostly because of rubygems - there are improvements we can make if we can ensure we work with future versions of certain gems.  Creating a binstub with hardcoded require paths earlier in the path than the gem binstub would also speed it up.
>
> We need to switch to persistent http connections but that will come with httpclient, and we *could* cache the API doc locally for a short time but have not put in place a mechanism to do that cleanly yet.
>
> Shell has some redundant costs cause we'd be tempted to add history, autocomplete, pretty print, etc.  Would much prefer to tackle all of the above first (and if you're volunteering to implement some startup optimizations that would be fantastic.
>

"Shell" is also sort of a loaded term.  I'd expect "rhc shell" to ssh me
into a gear or something.  Just 2 cents.

	-Mike

> On Dec 26, 2012, at 9:29 PM, Luke Meyer <lmeyer redhat com> wrote:
>
> > How hard would it be to add an "rhc shell" command a la "yum shell" - basically, just enter password and incur startup costs once, then use that to run as many rhc commands as you like?
> >
> > Would make for a nicer experience in a lot of ways. Not sure how difficult it would be architecturally though...
> >
> > _______________________________________________
> > dev mailing list
> > dev lists openshift redhat com
> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]