Initial ToDo List

[rushsteve1]

The first list of things to do in the project

• [x] Janet Bindings to Go
• [x] Web Servers
  • [x] HTTP
  • [x] FastCGI
  • [x] CGI
• [x] Converting Go's http.Request to Janet structures like Circlet's
• [x] Static file serving
• [x] Templates
  • [x] Go templates
  • [x] Janet Temple
• [ ] Built in libraries (see #5)
  • [ ] Custom library for Spinnerette
  • [x] Spork (required for Temple)
  • [x] janet-html
  • [x] Janet SQLite (possibly reimplement in Go)
  • [x] Janet JSON (same as above)
• [x] "Managed" SQLite database
• [ ] Dropping permissions to stay within webroot folder
  • Do we want to delegate this to the webserver itself? Or tell people to use containers?
• [ ] Ensure the Janet bindings don't leak memory
• [x] Some kind of cache system?
  • [x] Make sure stuff in the cache doesn't get GC'd

Questions

• How should Janet files be formatted? A main function?
  • A: Freeform, the script's return value is the response
• What should the return value of Janet files be? Should we support multiple kinds? (strings, Janet-HTML arrays)
  • A: Strings or Circlet-style response objects. Nothing else. Thanks to @eccentric-j for the feedback!
• How do we properly support shared hosts? Is FastCGI enough?
• Should we allow it to run other CGI scripts? (Leaning towards no)
  • No, let the webserver itself do that

[jaidetree]

Now that I've got a bit more perspective seeing it in action. supporting strings and response objects works quite nicely. At this point in time, feel it would be better to support strings and response objects.

My reasoning is:

1. By requiring (import html), and using that to encode the content as a string, then it's communicating that html is just a library and encourages others to create alternatives where if we implicitly handled arrays we're showing a strong preference to janet-html and strings over everything else. This keeps it a more even playing field.
2. Less ambiguity. If janet-html was supported implicitly, then newcomers may interpret it as either transforming into HTML or a JSON\edn tree.
3. Supporting more kinds of implicit response objects seems like a small optimization that may be best to incorporate upon user requests and after a bit of discussion.

Ultimately it's your call, but I do like the django philosophy of explicit is better than implicit, and reducing magic.

In so far though this project is coming together quite nicely! I can see myself enjoying working with it on personal projects I just want to get out of my head.

[rushsteve1]

ToDo List Part Duex

• [x] Fix up the module loader #5
• [ ] Change CLI flags and add a config file #9
• [ ] Flesh out the spin library (cc @eccentric-j)
• [ ] "Pretty" URLs support
  • [ ] index.janet files (or should it be init.janet like imports?)
  • Do we actually need this or should it be something the wrapping webserver does?
• [x] Temple support in Markdown files?
• [ ] Benchmark performance
  • [ ] Make sure the C bindings aren't leaking memory
  • [ ] Is the single-threaded performance OK?
• [ ] Basic security considerations like dropping permissions (don't go too crazy)
• [ ] Test with Apache and NGINX to see how it plays with actual webservers

Questions

• Do we want to setup some kind of docs site in order to dog-food the project? Is it too early for that?