Amirouche Boubekki <xxxxxx@gmail.com> 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.