On Tue, Jan 19, 2021 at 7:23 PM H. Nikolaus Schaller <[email protected]> wrote: > > Footer links to https://projects.goldelico.com/p/swi/. This is fine, > > but the path to contributing should be clearer. > > Indeed. > > Alternatively if you have access to cvs.savannah.gnu.org:/web/gnustep > you should find it in /softwareindex.
CVS! Eek. > > By the way since you are complaining: it *is* in the GNUstep repo: > > https://github.com/gnustep/gnustep.github.io/tree/master/softwareindex I'm not complaining -- however if I wanted to work on it (e.g. clean up by switching to PDO and placeholders instead of worrying if quoting function was called and worrying if it does the right thing for a particular input and for a particular language: https://ef.gy/php-use-pdo), I wouldn't know what's the "standard" version of the code that can be deployed. > > Oops. Even with a security issue I do not want to explain here. > Whom should I contact to remove a file from there including the index? Do we need to rewrite history or can the security issue be fixed without such measures? Rewriting git history is possible, but tedious and possibly dangerous. (Anyone who cloned a copy of the repo will get offered `merge` by default and might push back the old history.) Is the security issue present in the Savannah / projects.goldelico.com copy? Rewriting history in CVS would likely be infeasible without help from Savannah admins. Can you fix the issue without a history rewrite? Can we just delete the code in the current commit? > And, that there are two logins. I have no idea if that can be harmonized. Technically, oauth login to Github + org membership check, if you really wanted to do it. https://docs.github.com/en/rest/reference/orgs#check-organization-membership-for-a-user > Well, my dream is to write WebApps in Obj-C using OpenSTEP classes. > I.e. button = [[NSButton alloc] initWithTitle:@"press here"]; and have > the GUI class NSButton emit the necessary HTML+CSS+JS to present it to > the user so that he can press the button in his browser. So use the MVC > model in the App completely hiding that the user-interaction goes through > https (on a very abstract level there is no big difference between http > and X11 protocols connecting a server over the network with a display > and a keyboard). > > This could be achieved by a compiler from Obj-C to PHP or directly to > PHP byte-code... No translation into PHP needed. Simply implement an API in whatever language pleases you, and the web UI in Cappuccino framework. You get the full AppKit in the browser as a single-page app. Of course, that's completely unindexable by search engines, so it's only suitable for applications (e.g. administrative tools), not for presentation of content. But if you're going to work on presenting content, you need a templating system for content, not a UI framework. And implementing administrative UI in a Javascript-heavy framework may raise some people's eyebrows; but if you'll do something Javascript-free, then again, doing OOP UI just so you can render a static page and maintain some basic state in sessions is an overkill. > > Additionally, widest deployed Fediverse services are > > written in Ruby and Elixir respectively. > > Generally this is a Not Invented Here phenomenon. Choosing among a variety of languages feasible for web development is not an example of NIH. To be more direct: choosing non-PHP, non-Apache2 and non-MySQL is not NIH. At this time, anything new web-oriented I'm writing is using Go, nginx and PostgreSQL (or, in one toy project case, local file storage). > And since they do > not have a need to cooperate any more they compete. By inventing new > languages and making developers depend on them. If they would use > all the same language, developer would go away quicker. Standard > process in economics... I was pointing out they're not using PHP. There must be some reasons why people rarely pick PHP as a tool these days? I mean, consider the major reason why people used to pick it up: it's been popular due to availability of cheap shared hosting services, and because it was one of the easiest things to integrate with apache2. These days, apache2 isn't the default choice for a front server: that's nginx. https://news.netcraft.com/archives/category/web-server-survey/ In addition, there's an abundance of cheap hosting systems that we can really do better than an metastasized templating engine. (Unless you're actually writing OOP PHP, unit testing everything, etc -- at which point you've adopted so many good engineering practices you might as well be using another language. And probably should.) Please don't tie yourself to running everything on PHP or generating PHP from a language you create. Running an extra binary and having something like systemd (or even just a silly infinite-loop bashscript) autorestart it is not a big deal, and allows you to isolate application functionality into multiple unix users, in particular -- a distinct one from the frontend server (whether nginx or apache2 or whatever you want to put in front on the multiplexed serving port).
