[Libwebsockets] polling for file descriptor i/o

Andy Green andy at warmcat.com
Sun Mar 5 23:40:52 CET 2017



On March 6, 2017 3:26:37 AM GMT+08:00, Per Bothner <per at bothner.com> wrote:
>On 03/05/2017 10:35 AM, Andy Green wrote:
>> What I can imagine atm is
>>
>>  - allow listing .zip/;.jar/ in the fops struct instead of just one
>
>That would take care of my needs.
>
>>  - somehow maintain a list of fops and check all their .xxx/ in the
>lib code
>
>I do think having both a mount table and a fops list is redundant:
>There is nothing a mount table does that couldn't be done by a user
>open method.
>The mount table just does a replace of a prefix of the string that gets
>passed to open.
>An open method arbitrarily interpret the filename - including remap
>foo.zip to foo.jar.

Mounts have a lot more tricks than you are using so far... binding vfs namespace to the url namespace is just one job they do.  The other jobs can't be done in fops .open() because they are not related to file operations.

For example with mounts, in one step you may mount a cgi in the url space (signing up for this ml works using that, mailman is a perl cgi), and mount http redirects.  Mounts can also bind specific protocols to specific chunks of url space, allowing taking control of http callbacks there directly (POST test example works like that).

>If lws_find_mount were called at same time we call open I think it
>would make
>for a simpler API.  We could have a new function lws_find_and_open. 
>Each lws_mount
>entry would have an optional open method.  (NULL is the same as the
>default platform open.)
>lws_find_and_open searches the mounts list.  If the mount-point
>matches, it rewrites
>the URL as currently, and then tries calling open.  If the open fails,
>it continues
>to the next mount entry.  An open method can rewrite the filename and
>then call
>lws_find_and_open recursively if it needs to.

I'll think about it and look at the code... I agree there is crossover.  find + open per se is too aligned to only the fops-related mounts and bypasses too many existing steps between seeing it's a file-related mount, computing mimetype, check security (basic auth + generic sessions) etc.

>Regardless, the important goal for me is that we have a stable API
>you're happy with,
>so I can nag you to make a 2.2 release so I can remove the old crud
>from my sources :-)

Heh... likewise... but now is the time to sort out the fops api changes all at once if possible... few people used fops in user code until now I think.  Afterwards v2.2 will be the next goal.

-Andy



More information about the Libwebsockets mailing list