[Libwebsockets] polling for file descriptor i/o

Andy Green andy at warmcat.com
Mon Mar 6 03:14:42 CET 2017



On 03/06/2017 06:40 AM, Andy Green wrote:
>
> 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.

I added the ability to define up to 4 "fops signatures" like ".zip/" per 
fops, and set the fops_zip one to have .zip. .jar and .war.

I also implemented the fops linked-list, at context creation time user 
code can add to the end of this list either a single fops or a list of 
his own fops.

The "fops signature" scanning is done in common library code not in the 
zip fops open, it checks everybody in the linked-list excepting the 
first, platform fops.  Basically user-provided fops will be treated the 
same as internal ones for selection based on signatures in vfs path.

And this stuff should work even on oldstyle "manual" user code without 
mounts, if they use lws_vfs_file_open().

I confirmed it can serve with .zip or .jar as the mount origin.

These changes are all internal to lws from the POV of your code now 
AFAIK, you should be able to delete the symlink and use the .jar directly.

Plus or minus bugs I think that's it now.

-Andy

>
>> 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
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> https://libwebsockets.org/mailman/listinfo/libwebsockets




More information about the Libwebsockets mailing list