Re: Another attempt to approach Scheme websites Arthur A. Gleckler 11 Jul 2019 21:33 UTC
Amirouche Boubekki <firstname.lastname@example.org> writes: | The srfi website claims the following: | |> collecting, organizing, and serving indexes of |> Scheme code found in SRFIs, Scheme |> implementations, RnRS standards, etc. | | Is the above mission statement taken from the | SRFI website still valid? My view is that the people doing the work get to decide. However, I strongly believe that concrete goals are the most effective, and that in group efforts, agreement on goals is critical. For that reason, I think it would be best if we went after that original goal ("collecting, organizing, and serving indexes of Scheme code") first. Having achieved that goal, we'll have momentum, confidence, and an understanding of how each of us works that will let us tackle new goals. That's how we can build from simple goals to more ambitious ones. | By the way, I think that running biwascheme in | nodejs to expose a graphql endpoint is not a | good idea: a) biwascheme is basically a toy | until JS VM implement tail-call-optimisation, | which is not happening any time soon. b) graphql | will slow down the overall progress because we | need to understand how it works and same for | people that would like to consume the API. Since | there is no existing library, it is far from | easy to get started. c) running nodejs doesn't | deserve an explanation why it is a bad idea. It | will send a bad signal to the users. SchemeDoc | should promote Scheme, preferably scheme that | actively support Scheme. I agree about not using Biwa Scheme. I'm intrigued by how powerful GraphQL is and how easy it is to use. I've used systems like it and gotten huge benefits that way. On the client side, Lassi is right that Curl (or a simple HTTP library) is all one needs. On the server side, I agree that running Nodejs is the wrong idea in the long run. However, it's a great way to get started. Furthermore, as you can see from the GraphQL site, there are lots of implementations of the server side in different languages: https://graphql.org/code/ Some of them look small enough that I'm willing to believe that writing one in Scheme wouldn't be a huge effort. That could be a good medium-term project. | In another mail I did not send (!) I was arguing | that requiring a backend software would be | difficult to maintain. So, the idea that popped | is to use git to store the data and build a new | version of the website when it is merged in | master. This makes contribution from developers | easy (they just need git and an editor), it is | easy to maintain, it is fail-safe in the sens | that the schemedoc or the server disappear there | will be copies around that will be able to | re-launch the project. It should be possible to have both. If we agree on simple on-disk formats for storing the data, then it would be easy to generate new static web pages for some things automatically. A simple implementation of GraphQL could handle more complex queries. The key is that all of the software involved be open source so that anyone can take it and run it elsewhere.