On Sun, Oct 18, 2015 at 02:06:12PM +0200, Bodecs Bela wrote: > Dear Marton Balint, > > see may comments below. > > 2015.10.18. 1:10 keltezéssel, Marton Balint írta: > > > >On Thu, 15 Oct 2015, Bodecs Bela wrote: > > > >[...] > > > >>>>My enhancement does not alter the current behaviour in any way. > >>> > >>>Are you sure? What if somebody matched a semicolon, or a > >>>string which contained a semicolon in a metadata value? E.g.: > >>>m:timecode:00:00:00:00 > >>> > > > yes, indeed. > >This question still stands. Will the m:timecode:00:00:00:00 > >specifier work the same way as it did after your patch? I think it > >will not. > > > >[...] > > > >>I do not understand this. My patch only gives an opportunity to > >>use multiple specifiers in the same expression, it is not > >>mandatory to use it. The patch does not affect any existing > >>command line in any way. > > > >I don't agree, I think your patch changes existing behaviour and > >the proposed syntax limits future extensibility. > ok. > > > >>I also accept your concern about the future, but double > >>semicilon always will works for optional parameters. But may I > >>ask: would it be better to introduce a "special character" for > >>separating specifiers in the same expression? > > > >IMHO yes. You also have to know from the start that you are > >dealing with a complex specifier, in order not to break existing > >simple specifiers. > > > >>I accept it if you suggest one. I only need the functionality to > >>be able to give more criteria to select a stream as opposed to > >>current oppurtunities. I am not stuck to my suggestion. > >>Anyway, You may see my enhancement as you get many optional > >>parameters for the existing type, metadata and program_id > >>specifiers. :) > > > >It can be anything if it does not change existing behaviour, a > >complex specifier can be split to basic specifiers without > >worrying about the syntax of the basic specifier and if there is a > >well defined rule for escaping special characters. Also if it is > >readable to the user, that is a plus. > > > >The exact solution can be a bit about personal taste as well, but > >maybe something like > > > >(specifier)(specifier) > > > I like this version. So, there would be the original case: > specifier, and if you want to use more specifier, you should put > each of them into parenthesis (round brackets): > (specifier)(specifier) > I think it really won't break any current code > > >or > > > >+specifier+specifier > > > I think () is more readible and rarely used in specifiers. If it is > ok for you and others I would implement it.
i dont know which syntax is best but i agree with marton that the initial patch was not optimal. Also it seems the original patch changed the code quite deeply it would be better independant of syntax to have a more minimal change, that is if you intend to reimplement it anyway [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel