websocketd
websocketd copied to clipboard
joewalnes
Opinions: Should CGI support be removed from websocketd?
I'd like to get the opinion of the community on whether websocketd should continue to include CGI support?
What I mean by this is classic CGI support for HTTP requests. Specifically, the feature enabled using the --cgidir command line option.
The advantage of keeping CGI support is that some people find it a useful feature.
However, there have been many bugs in the CGI implementation, very few people actually use it, and it goes against the philosophy of websocketd being a small tool that does one thing and does it well.
Please respond with: "KEEP" or "DROP". And include your reasons.
NEUTRAL leaning towards DROP... just because not everything I need in quick and dirty way needs to be implemented as websocket and it's a good complimentary thing to have. But I understand that it should not go as feature that we need to nurture.
DROP
On Wed, Mar 4, 2015 at 8:17 AM, ctshh [email protected] wrote:
KEEP
— Reply to this email directly or view it on GitHub https://github.com/joewalnes/websocketd/issues/134#issuecomment-77114463 .
if it can be left in, but make it a compile time option that is default off.
then those that want it, can have it, those that don't, don't get it.
On 4/03/2015 8:51 PM, biafra wrote:
DROP
On Wed, Mar 4, 2015 at 8:17 AM, ctshh [email protected] wrote:
KEEP
— Reply to this email directly or view it on GitHub
https://github.com/joewalnes/websocketd/issues/134#issuecomment-77114463 .
— Reply to this email directly or view it on GitHub https://github.com/joewalnes/websocketd/issues/134#issuecomment-77126182.
Conditional compiling is not useful for most software. Maintaining code is still a necessity. Disabling feature by not using it is as good.
Please keep! I use it as a trigger to "git pull" configs and restart service on servers from our SCM.
Has anyone stepped up recently to work on it, fix it, or maintain it? if not, then it makes more sense to DROP it. this is a project by developers for developers. if no one is doing the work on it, then it's a lost cause.
@daledude are there alternatives for your use case? can anyone else suggest alternatives?
for me personally it's more important to see if this particular tool (websocketd) is good place to have CGI - serving as a feature. There is really not much to work on, things are stable and spec'd 20 years ago.
Websocketd CGI support is handy but does little good for users IMO.
Say you want to generate secure 10-min time-to-live token for javascript to interact with server via Websocket. If only tool that you have is a websocketd without CGI, you'd need static form of webpage that asks websocketd-hosted script for a token. With CGI you could just generate proper javascript and give it to client.
I'd argue that CGI-less way is slightly more complex but it's correct one. Gives ability to work well with CDNs, avoids "code writes code" pattern and does not rely on 20yr old technology.
IMO we should just set EOL time for this feature... guarantee to keep it in next releases for 3 months or so... @joewalnes ?
trying to use --cgidir so KEEP, but if it ain't working properly perhaps best to kill it.
