[dev] [draft] Proposal for jp subcommands

[Goffi]

On 17/11/2013 11:36, kedals0 at gmail.com wrote:
> Hi,

Hi

>
> I'm implementing subcommand for jp client. In the attached archive, you
> can find a first draft of this proposal.

It look great, thanks for your work :)

>
> Each features (or group of features, bring by a plugin for instance) are
> specified in a module which is imported by jp. The objective is to
> dynamically enable a subcommand (or group of subcommands) if the bridge
> offers required methods. this is currently not implemented but it will
> be easy to check this on subcommand module loading.

plugin detection is planned this week. We were supposed to release the 
0.4 today, but I guess we'll need an other week.

> In attachment, you will find:
> - main.py : load jp subcommand modules
> - base.py : base classes to write module
> - message.py : to send message (this works for me)
> - profile.py : to manage profile (this works for me)
> - file.py : to send files to contact (doesn't work for me). Moreover, I
>    have to add recv subcommands.

That seem a sane split for me.

>
> To see subcommands structure:
> $ python main.py --help

I have tried, but profile-delete, profile-info, profile-list seems too 
much positional arguments for the same category. I think it would make 
more sense to have profile delete, profile info, etc. Same thing for file.
Also, main.py should be renamed jp.

>
> About the profile that jp has to used, I propose to use an environnment
> variable such as SAT_PROFILE (not implemented yet). Moreover, when a
> command needs a profile, a '-p' argument can be specified which
> overloads the environnment variable.

No problem with that. Note that there is a default value, which is 
"@DEFAULT@" and use the profile declared as default in the backend. If 
there is in addition na environment variable, I'm bit worrying about the 
confusion, but that's not such a big deal.

> As you will see, the code is not really clean (ok, really dirty!). But I
> can't take time to clean it without your approval.

Anyway it's still better that the original jp one: it was just a simple 
script quickly done; but now we can start to use it as a real 
swiss-knife for SàT (and more generally XMPP) :). Don't worry globally, 
we are improving the code quality progressively, so it's not a drama if 
it's not perfect at the first shot;

>
> So I'm waiting for your opinion.

I'm ok for the way you are doing so far. If nobody else has suggestion, 
I think you can continue like this. Thanks again for your contribution :)

> +
> Dal.

++
Goffi

P.-S.: you should also import argparse for python 2.6, as it is standard 
only since python 2.7, but there is a version compatible 2.6 on pipy. jp 
should be Python 2.6 compatible (2.5 is old enough to dismiss it).