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

[Lukasz Marek]

On 17.02.2014 05:13, Michael Niedermayer wrote:
> 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

It is old topic, but some time ago I implemented most of it.
I'm pushing it in separate threads.

I included most of the remarks.