On 3 April 2015 at 15:22, Nicolas George <geo...@nsup.org> wrote:
> Le quartidi 14 germinal, an CCXXIII, Mariusz Szczepańczyk a écrit :
> > diff --git a/libavformat/avio.h b/libavformat/avio.h
> > index f61a8f8..51913e3 100644
> > --- a/libavformat/avio.h
> > +++ b/libavformat/avio.h
> > @@ -63,7 +63,10 @@ enum AVIODirEntryType {
> > AVIO_ENTRY_NAMED_PIPE,
> > AVIO_ENTRY_SYMBOLIC_LINK,
> > AVIO_ENTRY_SOCKET,
> > - AVIO_ENTRY_FILE
> > + AVIO_ENTRY_FILE,
> > + AVIO_ENTRY_SERVER,
> > + AVIO_ENTRY_SHARE,
> > + AVIO_ENTRY_WORKGROUP,
> > };
>
> Sorry if I missed the previous discussions on the mailing list (and if not,
> maybe just 8 hours before apply was a bit short for discussion), but I had
> a
> bit of a concern with this change.
>
> Until know, if you wanted to make a recursive listing, you just had to know
> that you had to recurse into directories. Now... should you recurse into
> shares? servers? workgroups? nobody knows.
>
> There should be some way of knowing whether an entry can be opened like a
> plain file, entered like a directory, or if it is just one of the weird
> things that lay in some corners of filesystems, without requiring an update
> when new types are added.
>
You have good point about that, but regarding a patch itself do you see it
wrong?
Sever, share, workgroup could be mapped to directory, but what happen when
we have delete operation available in API. You can delete directory, but
how to delete a server or workgroup?
IMHO patch is OK.
AVIODirEntry can be extended with a flag "can recurse" to indicate that,
but still I believe author of the client application must be aware of what
protocol they are using and how it works.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
