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

[Lukasz Marek]

>> +/**
>> + * 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.

Thanks for comments for everyone.

-- 
Best Regards,
Lukasz Marek

If you can't explain it simply, you don't understand it well enough. - 
Albert Einstein