On Tue, Nov 18, 2014 at 08:00:51PM +0100, Lukasz Marek wrote: > On 18 November 2014 03:31, Michael Niedermayer <michae...@gmx.at> wrote: > > > > > >It should be also possible to serialize an empty dictionary > > > > > > > >the serialization string should also contain a serialization format > > > >identifer/version otherwise future maintaince could become hard > > > >this identifer should specify the used separator chars > > > > > > Escaping OK, added. But what is the point of this? It will just > > > require additional function to remove these and pass it to > > > av_dict_parse_string. > > > Of course user will not have to remember separators. > > > > what will the function be used for ? > > will it be used to store dictionaries in files?, communicate them > > across the network? communicate between libs ? > > > > most likely the format will change over the years in some way, > > maybe dictionaries will get additional fields for type or maybe > > length for non-null terminated data, or ... > > > OK, with this assumption you are totally right. I'm just not sure it is so > likely. > >
> > how will that work without any way to identify the version or format? > > > > also a serialization stream thats self containd seems much nicer to > > handle as theres no need to keep track of the exact version (if we > > end up having more than 1) the used seperators, ... > > > > also consider 2 libs or apps to interface with each other using this > > serialization format, if one requires a change to the format how can > > the other know without a version in it, it would need to know it by > > external means. it can surely be done but it doesnt feel like > > something desirable > > > > I can do one of followings: > - I can move this function to ffserver_config.c, where it is needed as > presented here (to create simple pairs separated with comas) > - Rename function to av_dict_get_string or something so it wont get > confused with your idea of serialize function. I still think both version > has own usecases iam fine with either of these yes, my concern was that for serialization some compatibility issues need to be addressed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
