mastodon.ie is one of the many independent Mastodon servers you can use to participate in the fediverse.
Irish Mastodon - run from Ireland, we welcome all who respect the community rules and members.

Administered by:

Server stats:

1.5K
active users

#select

1 post1 participant0 posts today

So my dear #webdev bubble, specifically the #accessibility bubble, maybe you can help. I am finding the following issue an unexpectedly hard nut to crack:

- a `<select>` that has too many options making it annoying for users to find their option
- the field must be limited to the available choices
- it is part of a UI built with alpinejs.dev editing a list of items, hence the `<select>` gets constantly created/destroyed

Here's my research&thinking so far

#select #html #aria

🧵 1/9

alpinejs.devAlpine.jsA rugged, minimal framework for composing behavior directly in your markup.

Now that #swad 0.7 is released, it's time to prepare a new release of #poser, my own lib supporting #services on #POSIX systems, following a #reactor with #threadpool design.

During development of swad, I moved poser from using strictly only POSIX APIs (with the scalability limits of e.g. #select) to auto-detected support for #kqueue, #epoll, #eventports, #signalfd and #timerfd (so now it could, in theory(!), "compete" with e.g. libevent). I also fixed quite some hidden bugs, and added more base functionality, like a #dictionary using nested hashtables internally, or #async tasks mimicking the async/await pattern known from e.g, #csharp. I also deprecated two features, the periodic and global "service tick" (superseded by individual timers) and the "resolve hosts" property of a "connection" (superseded by a separate resolve class).

I'll have to decide on a few things, e.g. whether I'll remove the deprecated stuff immediately and bump the major version of the "posercore" lib. I guess I'll do just that. I'd also like to add all the web-specific stuff (http 1.0/1.1 server) that's currently part of the swad code as a "poserweb" lib. This would get a major version of 0, indicating a generally unstable API/ABI as of now....

And then, I'd have to decide where certain utility classes belong to. The rate limiter is probably useful for things other than web, so it should probably go to core. What about url encoding/decoding, for example? 🤔

Stay tuned, something will come here, maybe helping you to write a nice service in plain #C 😎:

github.com/Zirias/poser

Replied in thread

@Toasterson @astade Yeah, my main use case is socket notification, the lib offers #select and #poll as a base working across #POSIX, and I added #epoll for Linux and #kqueue for FreeBSD ... and as kqueue can do a lot more, I recently also implemented using it for signal handling.

I normally prefer my own local infrastructure, already fixed my Linux VM yesterday to test thoroughly with epoll (and, MAYBE, add signalfd support). So I might just install e.g. #OpenIndiana to also play around with /dev/poll. Had a look at an old SunOS manpage, seems simple enough to use 😉

First change since #swad 0.2 will actually be a (huge?) improvement to my #poser lib. So far, it was hardwired to use the good old #POSIX #select call. This is perfectly fine for handling around up to 100 (or at least less than 1000, YMMV) clients.

Some #select implementations offer defining the upper limit for checked file descriptors. Added support for that.

POSIX also specifies #poll, which has very similar #scalability issues, but slightly different. Added support for this as well.

And then, I went on to add support for the #Linux-specific #epoll and #BSD-specific #kqueue (#FreeBSD, #NetBSD, #OpenBSD, ...) which are both designed to *solve* any scalability issues 🥳

A little thing that slightly annoyed me about kqueue was that there's no support for temporarily changing the signal mask, so I had to do the silly dance shown in the screenshot. OTOH, it offers changing event filters and getting events in a single call, which I might try to even further optimize ... 😎