On Fri, Apr 3, 2015 at 3:22 PM, 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.
>
Right. Even though user should at least roughly be aware of what specific
type is representing, the api should provide a way to check if an entry is
readable as file or listable as directory.
I see two viable solutions: adding new flags to AVIODirEntry or adding
functions like:
bool avio_is_listable(AVIODirEntry *entry);
bool avio_is_readable(AVIODirEntry *entry);
(never mind the names, just example)
I tend to prefer the second option because these properties should
be completely dependant on type, and if it turns out they're not, the
implementation can easily be changed/expanded.
Regards,
Mariusz
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
