[Libwebsockets] libwebsockets project direction and organisation (was: Lws admin)

Roger Light roger at atchoo.org
Sun Oct 11 22:28:17 CEST 2015


Hi Andy,

Good to hear from you again.

I'm of a similar opinion to Bruce  - there's still plenty of work to
be done. For example, were I putting significant time into lws, the
thing I'd be looking at would be separating the core websockets code
from the poll() related handling functions. Maybe using an interface
closer to openssl, where there is an lws_read() that tells you whether
you need to read/write again. Something like that would allow lws to
be used where poll() isn't already being used, or with any given event
library. The existing poll() code could be a separate library to allow
relatively simple servers to be put together as is possible now.

I'd also look at improving the Windows support. The current code only
allows for 64 clients connected at once (WSA_MAXIMUM_WAIT_EVENTS),
which is a bit of a limitation.

I can't promise lots of time to the project but would certainly
consider being part of a team working on it.

Cheers,

Roger


On Sun, Oct 11, 2015 at 3:35 PM, Bruce Perens <andy.green at linaro.org> wrote:
>
>
> On Sun, Oct 11, 2015 at 4:15 AM, Andy Green <andy at warmcat.com> wrote:
>>
>>
>> >My recommendations from a organisational perspective are:
>> >
>> >- adopt the 'Collective Code Construction Contract' (aka C.4.1) as laid
>> >out here: http://rfc.zeromq.org/spec:22
>>
>> Ugh... let's worry about that later.
>
>
> Ugh indeed.
>
> If you have an urge to make rules for the people (like Andy) who really do
> the work, I think you are starting out on the wrong foot. Resist the
> tendency to over-organize. One of the main strengths of Open Source is how
> lightweight in management it can operate, removing encumbrances to producing
> code.
>
> We unfortunately have had a rise of managers and excessive formal process in
> Open Source, people who love to impose procedural rules on others to the
> point that the load of following them becomes an impediment, and even
> politeness police. They tend to drain the fun out of the project and thus
> any motivation to participate in it without being paid to do so.
>
>>
>> Well, there is some truth in that but github is a kind of cultural thing,
>> it's not a core requirement for running a project.
>
>
> We need to be careful not to put all of our eggs in the github basket and I
> really wish the community would try to be more distributed. Also, github is
> a commercial company with their own profit agenda, and their interest is not
> the same as that of the community they host.
>
> However, git  and the web git tools, sans github, are pretty easy to use and
> it should be hosted in many different places. My company hosts its own git
> web tools, and thus its web presence benefits in ways that github would
> otherwise benefit.
>
>>
>> this project is basically in maintenence mode now, or at least it should
>> be;
>
>
> Andy, I fully support that you as the coder, or whoever that is, should have
> control of the project when you're doing the work upon and I would hate to
> see this unnecessary organization foisted upon you.
>
> But unfortunately, your assessment of the completion or quality of the
> project is off base. It's not in finished state, the API has at least one
> real trap for the programmer that needs to be fixed,  the overall feeling is
> that it's "shaky" in quality, and my experience so far is that a serious
> user of the library will need to spend _days_ debugging it.
>
> I did a speech on Saturday at the TAPR Digital Communications Conference in
> which I recommended libwebsockets for an entire class of applications in the
> two-way radio industry, but cautioned developers that it was not in finished
> state and that they would have to invest significant time into debugging it.
>
> So, if you really believe the project is in maintenance mode, we need you to
> admit other folks to check in changes and do test releases. Or accept that
> they'll fork the project to do so.
>
> But hell no, I won't impose formal rules on developers while the project
> takes either path.
>
>     Thanks
>
>     Bruce
>
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> http://ml.libwebsockets.org/mailman/listinfo/libwebsockets
>



More information about the Libwebsockets mailing list