X-Sylpheed-Account-Id:1
S:andy.sharp@onstor.com
SCF:#mh/Mailbox/sent
X-Sylpheed-Sign:0
X-Sylpheed-Encrypt:0
X-Sylpheed-Privacy-System:
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	1758	BB375AF679D4A34E9CA8DFA650E2B04E01E2BE50@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 2 Jan 2007 10:55:53 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Jay Michlin" <jay.michlin@onstor.com>
Cc: "dl-Cougar" <dl-Cougar@onstor.com>, "Charissa Willard"
 <charissa.willard@onstor.com>, "Brian DeForest"
 <brian.deforest@onstor.com>, "Jeyaram Sankar Gurusamy \(HCL\)"
 <jeyaramg@onstor.com>
Subject: Re: cli refactoring project
Message-ID: <20070102105553.080645d8@ripper.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E01E2BE50@onstor-exch02.onstor.net>
Organization: Onstor
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I'm not sure how much of this is on point, but I've been thinking about
a couple of things.  One of them is the command line reading part and
then also the command line processing part.

A hallway chat with someone netted the notion that some are considering
the idea of using bash as the shell, which I think makes a lot of
sense.  Bash has the completion code built in: all we would have to do
is specify a config file for that piece.  This would allow us to
concentrate on just writing the individual commands themselves and not
have to spend any time on the shell functionality itself.  We could
also toss that code which would mean less code to maintain in the long
run.

I also spoke with Charissa about replacing the cccccccc daemon with a
lightweight web server.  I took a look at `boa' which is an open
source web server that is extremely light weight but also has very
good performance.  I'm aware of other embedded products that have a
web based management interface that use boa.(1)  Since boa doesn't have
native ssl support, stunnel will have to be used in front of it.  I
have researched many users of these two packages for exactly this
purpose.  The only question would then be what to use for a server back
end.  We could develop our own cgi program that interfaces directly
with the managment API, or we could develop a php/perl/apache type
backend that directly calls cli programs.

1 - http://www.securecomputing.com/index.cfm?skey=496

On Thu, 28 Dec 2006 14:32:42 -0800 "Jay Michlin"
<jay.michlin@onstor.com> wrote:

> Hello all,
> 
> Charissa brought up the question of how the ongoing CLI refactoring
> project will interact with Cougar. Her email below gives details.
> 
> Both are major strategic projects spanning many months with both major
> potential benefits and also considerable implications. To the extent
> that we implement Linux in Cougar, and perhaps take advantage of
> Linux' more capable shell or IP communication options, we could be
> affecting the CLI work.
> 
> That would be easy to remedy early in the project by adapting the CLI
> work to the Cougar environment we plan. It could be much harder later
> in the project.
> 
> So by this message, and Charissa's below, I'll alert everyone working
> on Cougar to the matter. Perhaps we should have a brief session early
> in the new year to make sure Cougar people are acquainted with the
> existing CLI and shell infrastructure to guide our decisions going
> forward.
> 
> Happy holidays,
> jay
> 
> -----Original Message-----
> From: Charissa Willard 
> Sent: Thursday, December 28, 2006 1:23 PM
> To: Jay Michlin
> Cc: Brian DeForest
> Subject: cli refactoring project 
> 
> Jay,
> 
>  
> 
> The parsing part of the cli refactoring project specifies refactoring
> the nfxsh code for parsing purposes. Before we continue down this
> path, I think we need to find out how long we will be supporting the
> nfxsh. When the nfxsh goes away so does this new parsing code. Larry
> said that they are deciding on the use of the nfxsh in Cougar. If the
> nfxsh goes away, we need to have a plan for how to handle cli
> commands outside of any existing nfxsh code. We should be doing this
> now, perhaps as part Cougar. Also, for the parsing design phase, it
> would be helpful to know what the new shell will be since parsing
> appears to be tightly coupled to the shell. Other issues we need to
> consider under Cougar are:
> 
>  
> 
> 1.)    Replacing sscccc, which is a wrapper around the nfxsh code that
> supports the web-ui.
> 
> 2.)    Communication for the web-ui when sscccc goes away. (Do we use
> a web server?)
> 
>  
> 
> With that said, I believe that the design specified in the FS may be a
> bit more complicated than it should be. Basically we just want to
> parse the command line, validate the parameters and populate the
> structures for the command's corresponding handler. The validation
> template specified in the FS seems a bit much. The example in the FS
> is as follows:
> 
>  
> 
> cluster add nasgateway NASGATEWAYNAME{"
> NASGATEWAYNAME,%s,^[a-zA-Z0-9][a-zA-Z0-9\-.]*[a-zA-Z0-9]$", OFFSET,
> LENGTH, LEN_OFFSET, LEN_LENGTH} -a IPADDRESS{%I, OFFSET, LENGTH,}
> 
>  
> 
> We may want to separate out the valid char string (in blue above) as
> the same chars should apply to most string parameters. We can have a
> default string and provide for exceptions to this rule by using
> something like a bitmap against the entire list of possible chars.
> Also, the use of an OFFSET (in green above) for mapping a parameter
> on the command line to its corresponding data structure parameter
> seems like it can be made simpler or perhaps explained in a bit more
> detail to show that this is indeed a simple/efficient method of
> handling the parameters. The alternative is to directly populate each
> parameter for the object being passed to the commands corresponding
> command handler. (This is what we currently do).
> 
>  
> 
> Let me know what you think about doing the cli refactoring project as
> part Cougar and not using the current nfxsh code.
> 
>  
> 
> Thanks,
> 
> Charissa
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
