From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Philip K." Newsgroups: gmane.emacs.devel Subject: Re: Proposal for an Emacs User Survey Date: Sat, 10 Oct 2020 12:35:33 +0200 Message-ID: <87ft6m9xmy.fsf@posteo.net> References: <364e5469-9c41-4453-36e3-5dd2d6c0694e@gmx.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16705"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Adrien Brochard Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 10 12:36:16 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kRCEZ-0004Du-9w for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Oct 2020 12:36:15 +0200 Original-Received: from localhost ([::1]:44126 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kRCEY-0003yQ-BZ for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Oct 2020 06:36:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40016) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRCE1-0003YE-JK for emacs-devel@gnu.org; Sat, 10 Oct 2020 06:35:41 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:46127) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRCDy-0007vN-G5 for emacs-devel@gnu.org; Sat, 10 Oct 2020 06:35:41 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 13F3A16005F for ; Sat, 10 Oct 2020 12:35:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1602326135; bh=Tyu/UDrrVLrMox2OskP3vS21qpv13kLVb5rM/4qa9z4=; h=From:To:Cc:Subject:Date:From; b=Hn+RVBSFxHUglHKnFYhOtOFn632qSr2l3hGTfUXO4mFZgrq1YmD2kqY9nOno4btqA G0xJ1nRyZKARl2etNSCqYxIh+WrEj5mtuJWcGOCOH93YzhJHaLp/lNwE9lV2I336gN 7dqplJ1/8XkDPK042S7gHPx2ihJ6F/aTMnwCG0J+Zlp6sH8BLssrp2WZlSbk97XHfZ 4BzkRH7VBd/e3vM2FvqJuguvOYPyaOfs5dSHOXxFhX4+tLJKkXtmhLtVCk3Yp+s2t/ GQyHn3CIjIwGQuItY5wHlstblSnR3AQuEKS8rc+R2cwH1vzWFiIw2e+nq4MDkn9JIH 2FIC5CpIhtK3Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4C7hD62lhjz6tmS; Sat, 10 Oct 2020 12:35:34 +0200 (CEST) In-Reply-To: <364e5469-9c41-4453-36e3-5dd2d6c0694e@gmx.com> (message from Adrien Brochard on Fri, 9 Oct 2020 15:52:22 -0400) Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/10 04:47:47 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:257314 Archived-At: Adrien Brochard writes: >>> - cleaner UI, not just HTML embedded in the code >> >> What would you have in mind? I know that my example is simple, but I >> prefer that to sites that take forever to load and reload everything all >> the time, for no apparent reason. > > The most obvious reason to me is that user error handling is pretty > poor. Because there is no JS, we cannot offer front-end validation, that > means that the backend server is responsible for validating fields > submitted. If validation does not pass, the page must "reload" for the > user and it needs to show exactly what went wrong and preserve the user > input. That's my definition of a site that reloads all the time. That could be mitigated with a "graceful degradation" approach, since most people do have javascript activated by default. HTML5 also has a few attributes that could help, such as pattern or required, depending on what questions are being asked. >>> - mysql instead of sqlite, which also implies a mysql instance running >> >> SQLite is actually surprisingly resilient, according to [0]: >> >>> SQLite works great as the database engine for most low to medium traffic >>> websites (which is to say, most websites). The amount of web traffic >>> that SQLite can handle depends on how heavily the website uses its >>> database. Generally speaking, any site that gets fewer than 100K >>> hits/day should work fine with SQLite. The 100K hits/day figure is a >>> conservative estimate, not a hard upper bound. SQLite has been >>> demonstrated to work with 10 times that amount of traffic. >> >> But either way, I used sqlite to avoid setting up a RDBMS. >> >> [0] https://www.sqlite.org/whentouse.html > > SQLite is resilient but it's dangerous to use it with multiple threads > like how your go server does. You could use a single channel model to > write records one at a time but now you have a risk to lose data from > memory if your service restarts. I'm familiar with the danger, but it shouldn't be a problem. As pointed out in [0], one can activate the SQLite mutex per flag. But at the same time, even sites as popular as Hacker News are alleged to use SQLite as their backend. [0] https://github.com/mattn/go-sqlite3/issues/249 >> >>> - DOS protection, maybe some rate-limiting and IP blocking >>> - HTTPS, thankfully it's easier now >> >> AFAIK these things can usually be handled by a frond-end such as NGINX. > > That's true it can, but that means you need to deploy and configure one. > https://www.nginx.com/blog/rate-limiting-nginx/ > https://nginx.org/en/docs/http/configuring_https_servers.html Perhaps using Guix could make that easier: https://guix.gnu.org/manual/devel/en/html_node/Web-Services.html#NGINX? >>> - monitoring, how do we know the service is running as expected >>> - logging, and how to store logs for debug >> >> If there is any interest, extending the example to support this would be >> feasible. The "20%" you mention aren't easy, but from what I see it >> shouldn't be too hard either. > > You're absolutely right. None of it is "too hard". But the problem is > just how much time and effort are we willing to put into it. If the goal > is to make an open source polling platform that we can re-use in the > future, then absolutely all of this can be done. But if we treat this as > a one-off and see how it turns out, the scope seems exaggerated. Depending on how many people participate, it would be interesting the repeat the survey year-by-year, so that trends and changes in the user-base can be recognized. -- Philip K.