Keeping backwards compatibility sounds like a wonderful idea.
If you are willing to do the work to support both, that sounds good. I suspect
that it will take some work to make sure that everything works well.
Part of my problem is that I will have to support old versions of xfreerdp,
as well as new versions. My customers may be using a 2 year old Ubuntu,
which doesn't have FreeRDP. 2 years from now, that will probably remain the
same.
Let's consider the documentation as well. With the old style arguments,
there are 3 places where each argument appears:
client/X11/xfreerdp.1.xml, for documentation
libfreerdp-utils/args.c, in the help section
libfreerdp-utils/args.c, in the argument parsing
In the new style arguments, args.c is replaced with
client/common/cmdline.c, which contains 2 references to every argument
argp_parse allows the "--help" output to be combined with the argument parsing,
which gets rid of one of the duplications. "--help" includes arguments
if and only if the arguments are actually parsed. You still have to worry about
the man page, but you reduce the duplication a little.
When long command line arguments were first added, they were a bit
controversial.
There was a stage when "+" was used rather than "--", but most innovation
in command line arguments have been minimal since then.
----- Original Message -----
From: Marc-André Moreau <marcandre.mor...@gmail.com>
To: Christian Nilsson <nik...@gmail.com>
Cc: freerdp-devel@lists.sourceforge.net
Sent: Sat, 01 Dec 2012 08:43:05 -0800 (PST)
Subject: Re: [Freerdp-devel] Why is there a change in the command line
interface?
I've designed a very generic command-line parser with that in mind. I've
been told by some people on IRC that they were fine with just moving on to
the new command-line interface, so I didn't bother doing the extra work for
keeping backwards compatibility forever. However, it is definitely doable.
In other words, here's the work that needs to be done:
Implement the POSIX-style command-line syntax parsing in the parser, detect
it, and use it when detected.
Implement a detection method for the old arguments (can be done by checking
for the hostname being passed last without /v:, and the syntax being
POSIX/Linux) and offer backwards compatibility for the old set of arguments
in this case. This should be fairly easy to do for simple arguments, but it
will require more work for stuff like --plugin.
This way, we can offer backwards compatibility, and we can offer both
command-line syntaxes (windows-style, linux-style), such that everybody is
happy.
On Sat, Dec 1, 2012 at 11:31 AM, Christian Nilsson <nik...@gmail.com> wrote:
> Hi,
>
> Just chiping in that I like the old command line interface to stay, at
> least for a foreseeable future.
> The reason being loots of scripts that I don't want to (be forced to)
> change.
> So for atleast, say a year it should still be possible to use the old
> options.
>
> This change in command line interface have been scaring me since the first
> time i read about it.
> I see some similarities to the mstsc options, but should freerdp really be
> a copy of mstsc? (My answer is no)
>
> If there is ways that make it easier to use for the user then that's all
> good, but (forced) change is always negative, for every one else then the
> one that made the change (more or less and that is in human nature)
>
> I find it hard to read command lines that do not have spaces in them.
>
> Reusable parser functions and this should not be a issue at all!
>
> regards
> Christian
>
> On Sat, Dec 1, 2012 at 5:14 PM, Marc-André Moreau <
> marcandre.mor...@gmail.com> wrote:
>
>> Hi olav,
>>
>> You are right about commands like /a (that 'a' stands for 'addin' btw, I
>> decided to with the more microsoft-like terminology). I do not intend to
>> leave it that way. I'm thinking of adding channel specific options, they
>> just aren't there yet. For instance, you can now enable clipboard this
>> way:
>>
>> +clipboard
>>
>> Instead of doing:
>>
>> /vc:cliprdr
>>
>> This is much easier to remember and understand for users
>>
>> There is more work to be done on the device redirection channels and the
>> other channels, it's not fully done yet.
>>
>> For drive redirection, I was thinking of an option like /drive with
>> optional arguments, etc.
>>
>> As for using Linux or POSIX style syntax, I think there's enough people
>> asking for it, so I'll simply work on implementing that in my command-line
>> parser such that both command-line syntaxes will be usable.
>>
>> If the current "examples" are:
>>
>> xfreerdp connection.rdp /p:Pwd123! /f
>> xfreerdp /u:JohnDoe@CONTOSO /p:Pwd123! /v:rdp.contoso.com
>> xfreerdp /u:JohnDoe /p:Pwd123! /w:1366 /h:768 /v:192.168.1.100:4489
>>
>> They would become:
>>
>> xfreerdp connection.rdp -p Pwd123! -f
>> xfreerdp -u JohnDoe@CONTOSO -p Pwd123! -v rdp.contoso.com
>> xfreerdp -u JohnDoe -p Pwd123! -w 1366 -h 768 -v 192.168.1.100:4489
>>
>> One other question: should we use a space or a sign like '=' to separate
>> the option name from its value? For parsing, it easier if there are no
>> spaces. If we use '=', it would look like this:
>>
>> xfreerdp connection.rdp -p=Pwd123! -f
>> xfreerdp -u=JohnDoe@CONTOSO -p=Pwd123! -v=rdp.contoso.com
>> xfreerdp -u=JohnDoe -p=Pwd123! -w=1366 -h=768 -v=192.168.1.100:4489
>>
>> What do you think?
>>
>> On Sat, Dec 1, 2012 at 3:23 AM, olav <ola...@online.no> wrote:
>>
>> > Hi,
>> >
>> > I think it is ok to shorten the command-line options.It is a correct
>> > presupposition that the user should not have to care about the details
>> > of the program's working, as for example which shared objectfiles to
>> > load. The commandline options should be about which goals to reach, for
>> > example forwarding of local home dir. Then: to get rid of commands for
>> > sub-plugin-loading is fine. The commandline options should be easy to
>> > understand and remember.
>> >
>> > In my opinion either "/a" nor "--plugin rdpr etc..." is easily
>> > understood and remembered. I would say that "--drive=<remote
>> > drive>,<local dir>" is. What relation is there between "a" and drive,
>> > disk or dir?
>> >
>> > I think that the options should use the standard of one hyphen for
>> > one-letter options, and two hyphens for more-than one letter options. I
>> > see is no significant gain in leaving this part of the standard. The
>> > problem with + and - then could could be solved with two sets of
>> > options: --enable-this and --disable-this. Or like the options to
>> > configure: --enable-this=off
>> >
>> > The quantum of typing is no big deal. Deviating too far from the posix
>> > standard is.
>> >
>> > Olav.
>> >
>> >
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Keep yourself connected to Go Parallel:
>> > INSIGHTS What's next for parallel hardware, programming and related
>> areas?
>> > Interviews and blogs by thought leaders keep you ahead of the curve.
>> > http://goparallel.sourceforge.net
>> > _______________________________________________
>> > Freerdp-devel mailing list
>> > Freerdp-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/freerdp-devel
>> >
>>
>> ------------------------------------------------------------------------------
>> Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net
>> _______________________________________________
>> Freerdp-devel mailing list
>> Freerdp-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freerdp-devel
>>
>
>
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net/
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
