Hi, About supporting one of the two syntaxes at once: no way. Many of you are not happy of the changes because it means you'll have to adapt your scripts. If we were to support one syntax on Windows, and one syntax on non-Windows systems, it would effectively mean that a cross-platform script invoking xfreerdp on Linux and wfreerdp on Windows would need to produce two different command lines. And no, dropping support for the Windows-style command-line syntax is not an option. I don't know if you have realized it at this point, but I'm the guy stuck in the middle trying to please everyone at the same time, so please comment in consequence on this.
About documentation: we can simply choose one syntax to be used in most documentation, solving the "nightmare". About parser bugs: I'm the one who unit tests his code the most, and the parser I've written is not an exception to this. Of course, more tests can be written, but this is nothing that can't be handled. Also, the new parser does automated validation according to the given syntax, and has a list of error codes that it can return. Again, this can always be improved on, it's nothing set in stone. I'd rather have you guys comment on edge cases you might have found that would be worth handling. The more you can point out, the more I can not only fix, but also ensure functionality through improved tests. Making this parser rock solid is not an issue. Now if parser bugs are syntax specific, there's one easy way to test this: parse the same commands in both syntaxes, compare the output, write many test cases like this. About making code bigger, really? Keeping backwards compatibility keeps the code bigger as well, and it doesn't seem an issue if that's what you want... On Tue, Dec 4, 2012 at 4:22 PM, Otavio Salvador <ota...@ossystems.com.br>wrote: > > > > On Tue, Dec 4, 2012 at 4:33 PM, Marc-André Moreau < > marcandre.mor...@gmail.com> wrote: > >> The current syntax detection method is very naive and can simply be >> replaced by a much better one that will work with much more accuracy. For >> instance, we know what the expected options are, one very accurate way >> would be to parse the argument vector twice, one for each syntax, and >> count >> the number of recognized options. This way, the parser would effectively >> know what is an option and what is a value, avoiding potential conflicts >> with values like what you pointed out. It's nothing that can't be fixed, >> yet you speak like there is no good solution to this problem. It's a >> no-brainer. >> >> Also, I can guarantee you this is a one-time change. I have been meaning >> to >> do it for a very long time but never got the time to do it. Now is the >> time, in preparation for the 1.1 release. >> >> I don't mind backwards compatibility for a period of time, but let's face >> it, I know I'm going to have to do all the work necessary for this. Feel >> free to prove me wrong, but I'm kind of disillusioned right now. > > > I don't like to Windows-like parsing but I also think we shouldn't keep > both supported. It has many cons: > > * makes documentation a nightmare (you need to always explain it twice) > * makes support a nightmare (we'll need to be able to understand two > command lines when reading issue requests) > * makes code more subtle to bugs (some bug might be parser specific) > * makes code bigger for no reason > > From my point of view, it can be done (as I did for rdesktop) using an > wrapper. > > One thing I dislike a lot is such a big change in a short version > increment. This is something I don't like so my vote is to choose a > command line format, stick to it and bump version to 2.0. > > We can, add an commandline option which works in 2.X only and make easy > for abstraction code to detect which version is being used. Besides that I > think is buying problems and work for ourselves... > > Regards, > > > -- > Otavio Salvador O.S. Systems > E-mail: ota...@ossystems.com.br http://www.ossystems.com.br > Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br > > ------------------------------------------------------------------------------ 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
