CLI built-in commands

Charles Crouch ccrouch at redhat.com
Fri Jun 1 14:18:46 UTC 2012


Will this impact existing scripts that are working fine right now? I don't want to ask people to change their scripts because of bugs they are not hitting.
At best these could be probably be deprecated prior to another major JON release.

----- Original Message -----
> 
> 
> 
> While I have NOT look at the actual code I also +1 the approach.
> On Jun 1, 2012 2:42 PM, "Michael Foley" < mfoley at redhat.com > wrote:
> 
> 
> 
> 
> John ... I like your thought process. Specifically ...
> 
> 
> 
> 
>     • spending time to understand the root cause
>     • proposing a countermeasure that addresses the root cause ...
>     (ie, not a band-aid fix)
>     • thinking about the overall value-add
>     • understanding that features are an asset, but code is a
>     liability ... and
> 
> 
> 
> If we can do away with some non-value-added and buggy code ... then
> I'm +1.
> 
> 
> 
> 
> 
> From: "John Sanda" < jsanda at redhat.com >
> To: rhq-devel at lists.fedorahosted.org
> Sent: Friday, June 1, 2012 7:36:47 AM
> Subject: CLI built-in commands
> 
> While working on https://bugzilla.redhat.com/show_bug.cgi?id=824129 I
> spent some time thinking about the problem. I concluded that there
> is a bigger issue at hand than just parsing quotes incorrectly.
> 
> CLI code is JavaScript with the exception of a handful of built-in
> commands. So we have the majority of code that is written and
> executed as JavaScript, and then we have a small fixed set of
> commands that executes as Java. Because of this we have multiple
> layers of parsing code. These multiple layers of parsers have led to
> this bug as well as bug 813912 , and others. To make things even
> worse, not all of these built-in commands are available in batch
> mode.
> 
> I want to propose that we do away with these built-in commands. The
> functionality provided by the built-in commands should be
> implemented within the framework in which users operate; in other
> words, the functionality should be exposed via functions and methods
> of objects that are available in the script bindings. In so we
> doing, we can eliminate most if not all of these buggy parsing
> layers, provide a uniform and consistent syntax, and take better
> advantage of the features that JavaScript has to offer (if we so
> choose). I do not see any value add in these built-in commands as
> opposed to providing the same functionality in JavaScript, whether
> that comes in the form of actual JavaScript code or as exposed,
> native Java objects.
> 
> - John
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list