Hi, The fact that some of the discussion happens on IRC is partially behind this. I've discussed this a lot on IRC but not on the mailing list. I usually get a lot more advice on IRC than on the mailing list, and what came out of the discussions I had with other community members is that while they did find the windows-style syntax weird, they did agree that it makes commands much shorter. The decision of simply dropping the old syntax was also taken from comments of the people that care about giving me daily advice on IRC, who said they'd rather move on than always keep the burden. Many of the people involved in the discussions actually had to rewrite their scripts as well, but still thought it was a good thing overall. As for you Jay, since you're a core dev, I've said it many times: it'd be important that you at least idle on #freerdp to avoid missing discussions in which you'd like to be involved.
Nevertheless, I had designed a generic parser from the start, thinking that we could support more than one syntax to please everyone. I wasn't really expecting everybody to be ok with using only the windows-style syntax, but with a bit of luck maybe it would have been a change that would have been accepted almost as is. Wishful thinking, maybe, but I was at least prepare the make the changes necessarily, it took me less than an hour to get the alternate syntax in. I know people are really picky about whatever has the word "interface" in it, and CLI is no exception. As a start, I knew that the CLI would require a full redesign. We've been carrying the same options over a long period of time, and most one-letter options have been taken. I wanted to add a lot of fine-grained options to accommodate for many cases that would have otherwise required registry configuration or recompilation, and many of the one-letter options were either not frequently used, or fairly close to other multi-letter options. I also wanted to free some of the conflicting one-letter options for other more frequent use. I could have used an arbitrary basis for the new set of options, but I chose mstsc. mstsc doesn't have a lot of options so there aren't many options for which the name is fixed. Becoming mstsc-compatible was not much of a big deal at this point, and it is something which I care about, since we can effectively become a drop-in mstsc replacement for anything invoking mstsc. It also gave a baseline to get started, and provided the syntax for where to put in the .rdp connection file for which I had recently added support. Why decide arbitrarily to use different options? It would have not given use mstsc compatibility for not that much of a reason, really. With this compatibility, just about any user that has been using mstsc for a long time and migrates to FreeRDP will not see a difference. The idea of using mstsc as a baseline for the options was also inspired from a project called Remote Desktop Plus: http://www.donkz.nl/ It doesn't matter if you've used the tool or not, I have actually never used it myself, but it is basically an improvement on top of mstsc to add just about any command-line options that a system administrator would wish to have. I have not used Remote Desktop Plus as a basis, just mstsc, but the idea that this tool was designed by a system administrator for other system administrators made it seem like it was not a bad idea. The real problem with mstsc is its lack of command-line options, not the options it has. We do not have this problem, and we're free to add just as many options as we like to fit our needs. Having the first argument be the optional .rdp configuration file makes it easier for file association. I wish to have FreeRDP easily installed on Windows and associated with .rdp files as a replacement to mstsc. The same can be done on all platforms. This is something I care a lot about along with .rdp file support. In the new CLI, I've tried finding names which were short but still meaningful. Some of the current options will find more meaningful equivalents before the 1.1 release, especially for commands like /vc or /dvc. I wish to provide feature-specific options for every channel, since the user shouldn't have to know about the internal architecture of FreeRDP in order to invoke it. The user cares about using a microphone, watching videos and getting sound, but does not care about the fact that this is done using dynamic virtual channels, and cares even less about remembering their names. Many one-letter options were probably chosen as such because they were short, but their original meaning is hard to guess. One example is -c and -s. Can you guess what they mean easily unless you've been using them for years? -s: set startup-shell -c: shell working directory /shell Alternate shell /shell-dir Shell working directory One other reason for going with the mstsc CLI as a basis was to be able to use + and - options, which are really really convenient. However, it requires that - is not used for regular arguments, if we interpret it as a minus. If / used instead of - and --, then + and - becomes possible. I really care about keeping this gain, and I personally use it every day now. Some other community members on IRC also reported they were using it now, after passing the mental barrier of "it looks weird". If you don't like the new syntax, don't want to use +/- and /, then fine, no problem. The compromise is supporting both syntaxes. Asking me to drop the advantages of the other syntax, however, is not a "compromise". If I have to satisfy everyone, then can I at least be satisfied as well in the process? The syntax you guys like, fine, backwards compatibility, fine, but don't ask me to drop support for the stuff you personally do not care about, because others actually do care, and are also in their right here. All I'm asking is that there is a compromise done on this. I've added support for the syntax you guys like, I've said I was going to provide backwards compatibility for the old options as well, but then, why ask me to drop support for the rest? That's not what I call a "compromise", especially when I'm the one who's been spending sleepless nights on this. On Tue, Dec 4, 2012 at 7:35 PM, Jay Sorg <jay.s...@gmail.com> wrote: > > I know it is lots of work and I don't want to see extra code as well but > > there is one thing that I don't understand. > > > > "And no, dropping support for the Windows-style > > command-line syntax is not an option" > > > > Why? This have not been explained, or i totally missed it. > > I've read about the nice +feature -feature etc but not really why we need > > to have the windows options at all. > > Yes, Marc, can you explain. I missed that too. > It seem like no one wants the windows style. We should always listen > to the community. > > Jay > ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
