Shirakumo / radiance

A Common Lisp web application environment

Home Page:https://shirakumo.github.io/radiance/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

General Cleanup and Janitor Action

Shinmera opened this issue · comments

There are a lot of dirty and gross parts in radiance-web and radiance-core that are both hard to understand and probably just waiting to bug out. A general cleanup is direly needed.

  • Things in radiance-web/toolkit and radiance-core/toolkit seem to be in one or the other without much rhyme or reason.
    See next
  • Generally the differentiation between -core and -web does not seem to be outlined well-enough. Either find a proper separation of concerns or merge the two together.
    The two have been merged.
  • api-output is complicated and not clearly defined in what exactly it is supposed to do. Rethink and rewrite.
    I apparently did this at some point, or at least I can't see anything wrong with it at this point.
  • api-serialize is completely broken as it is now. The mechanisms for defining what kind of objects are serialized how need to be lexically overridable so that outputs can remove/redefine things as they seem fit and only use the defaults when appropriate. Some kind of mergeable-lookup table for hooking the types to the serializing functions is needed.
    Solved.
  • api-call and make-api-call are almost identical. Find some way to merge them / reduce duplication.
    Calling convention rewritten.
  • Reconsider the error handling in the api-page. Probably all errors should be serialized, but responses should carry the correct return-code.
    No, it might always happen that a generic error page is presented for some other reason, so any and all non-api related errors should result in a page.
  • handle-condition needs to be rewritten to only call the debugger if one is available and *debugger* is non-NIL. It should also offer a restart to simply relay the error.
    Available present-error-page restart during debugging.
  • Reconsider the role of redirect. Maybe it should act as a return-like construct.
    No, that would require it to be a macro and would end up being more surprising than the alternative.
  • Currently the error catching and handling in request is awful and hard to understand. Rewrite that part completely.
    request has been rewritten.

There's probably a lot more still.