[FFmpeg-devel] [RFC] Browser remote content API

[Michael Niedermayer]

On Sun, Feb 16, 2014 at 06:52:21PM +0100, Lukasz Marek wrote:
> >>+/**
> >>+ * Allow to read content of the directory.
> >>+ *
> >>+ * @param url          directory to be listed.
> >>+ * @param[out] entries sorted directory entries.
> >>+ * @param sort_flags   combination of AVIO_SORT_* flags.
> >>+ * @param options      protocol options.
> >>+ * @return 0 on success or <0 on error.
> >>+ */
> >>+int avio_list_dir(const char *url, AVIODirEntryList **entries, int sort_flags,
> >>+                  AVDictionary **options);
> >>+
> >>+/**
> >>+ * Free directory entries list.
> >>+ */
> >>+void avio_free_dir_list(AVIODirEntryList **entries);
> >
> >I think an opendir()/readdir() style API would be better. You're not
> >forced to allocate a huge list of entries (and reallocate it several
> >times as you append to it), and you wouldn't need to allocate memory
> >for each entry.
> >
> >Details could be queried by a separate stat()-style function. The
> >function could take the opendir() handle as parameter, so that in case
> >of remote protocols the entry could be retrieved from a cache. It also
> >could help keeping down the load, as it's the user's decision whether
> >to call the underlying stat() implementation.
> 
> I had this in mind, but I'm not sure it is good idea. Using a cache
> would require a context, proof me wrong, but there is any in public
> API and I think in many cases it would ended in situation where the
> same data are in cache and on user's structure. FTP and HTTP
> protocol provide all information at once and second function may
> just confuse user which may not know these protocols. Your solution
> would make sense for file protocol, but I treat it as minor in this,
> because this API is more relevant for network protocol. One case
> that make it more sense is sftp, but I have to check its API.
> 
> Now I have an idea to add a flag in AVIODirEntryList to inform user
> that extra information may be obtained with stat function, but it
> still doesn't solve problem with context. Connecting to server and
> authorization may be slow and it may takes much longer than querying
> all params during single call. I prepare it just for GSoC project
> and until someone gets deeper into it, it is hard to predict all
> issues that may occur.
> 

> As a comment for all other comments from you, Michael and Nicolas, I
> wanted to make this API simple and I omitted some details as file
> permissions etc. I see you all point it so I will resent updated
> version later.

i didnt mean that all that has to be added now, if you had other
plans, it was more meant to make sure its not forgotten/missed

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140217/f3326508/attachment.asc>