qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "lahiru gunathilake" <glah...@gmail.com>
Subject Re: GSoC - Lahiru's CLI for JMX
Date Tue, 27 May 2008 07:26:44 GMT
Hi marnie and aiden,

On 5/22/08, Aidan Skinner <aidan@apache.org> wrote:
>
> On Sun, May 18, 2008 at 11:54 AM, lahiru gunathilake <glahiru@gmail.com>
> wrote:
>
> > Here's my basic idea about the project and please treat this as a draft
> SRS
>
> Sorry, I'm not familiar with that acronym, what is SRS?
>
> >   -  First I think I have to figured out what report formats to be given.
> >   May be multiple report formats and user can select one at a time. (And
> I
> >   think you have to tell me we need these report formats and I will
> implement
> >   them).
>
> I think we need to let the user define the report format, it's hard to
> predict users requirements for things like this in advance and giving
> them the flexibility to decide for themselves is generally a good
> move. Having said that, we probably should define some canned reports
> which we can ship both as an example of what the tool can do and for
> general user. Off the top of my head the one I would be most
> interested in would be one showing queue name, queue count, queue
> depth and number of consumers.
>
> >   -  This runs as a daemon and I think this won't be a big thing since we
> >   can use cron to implement this(as Marnie said) or we can use sleep with
> Java
> >   threads and run the same code time to time.
>
> Running via cron is quite different from running as a daemon, one
> starts a new process every time and one keeps a process resident.
>
> >   -  And what data we give in reports ...obviously user have to specify
> it
> >   somehow, may be with command line options or using a configuration file
> and
> >   I prefer use command line options. *I have no idea* about which kind of
> data
> >   user is going get in report format.(Is it like give me all the queue
> details
> >   for each and every five minutes, which means generate 12 reports for an
> hour
> >   and do the same thing until broker is up) am I correct and I need a
> feed
> >   from you about this question.
>
> I think having both a configuration file and command line options
> available is probably the best tactic here, again flexibility is the
> key.
>
> >   -  When user is going to configure which data he need in report format?
> I
> >   thinks when user logged in user have to configure it by some command
> and
> >   each argument have it's default value and then user have to give
> another
> >   command to start the thread.
>
> I think the start command could be wrapped up into the report
> creation, maybe as a --daemon/-d switch or implicitly when they
> specify the frequency with which to run.
>
> >   - Now user is working in interactive mode and if user is interest on
> >   generating reports user have to configure the report generation mode as
> I
> >   discussed with previous section.If user is not interest generating
> reports
> >   user can start on working in interactive mode from the beginning. Or
> user is
> >   only interest on generating reports, after successful configuration of
> the
> >   report generation mode user can type exit command and exit from the
> >   qpid-admin prompt and start the normal work with the command line.
>
> I think having a shell mode with which the user can interactively
> explore the current broker status is a great idea! Have you looked
> into whether there are Java libraries which implement GNU readline
> like functionality?
> Yes I found a library which is having BSD License and I started the coding
> and initially I was able to use the library and write the basic command line
> interpreter which is capable of reading the commands which user type and
> quit from the qpid-admin-$ prompt if user type exit of quit. I think I have
> to inform you what I am doing once for two days and could you please tell me
> how should I do that. Is it enough if I drop a mail.



Thanks
lahiru

>   - We have to figure out what are the list of command we are going to
> >   allow the user to work in interactive mode and what sought of a work it
> does
> >   with each and every command.* I need a feed from you in this location
> >   again*. If you can tell me what are the operations I have to allow
> users to
> >   do in interactive mode then I can create a command name for each
> operation
> >   with appropriate parameters.
>
> I would imagine that it's really a case of list and info for each
> object to start with, and then we can define the more 'active'
> commands (such as clear for a list) when we consider each object.
>
> > May be we can ask these questions from our users as well.
>
> Getting early user feedback on this is going to be very valuable. Have
> you subscribed to qpid-users yet? It's probably a little early to
> solicit feedback from them on a design, but I think getting their
> input when you have a functional prototype ready would help a lot.
>
> I'm going to be away for a few days, but will be checking my email
> semi-regularly, I shan't be available via IM until Tuesday
> unfortunately. :/
>
> - Aidan
> --
> aim/y!:aidans42 g:aidan.skinner@gmail.com <g%3Aaidan.skinner@gmail.com>
> http://aidan.skinner.me.uk/
> "We belong to nobody and nobody belongs to us. We don't even belong to
> each other."
>



-- 
East or West
Mahindians are the
Best... !

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message