[FFmpeg-devel] [PATCH 07/11] lavu/dict: add av_dict_serialize

[Michael Niedermayer]

On Tue, Nov 18, 2014 at 08:00:51PM +0100, Lukasz Marek wrote:
> On 18 November 2014 03:31, Michael Niedermayer <michaelni at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141118/a2d34d00/attachment.asc>