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 are a lot of dirty and gross parts in
radiance-webandradiance-corethat are both hard to understand and probably just waiting to bug out. A general cleanup is direly needed.Things inradiance-web/toolkitandradiance-core/toolkitseem to be in one or the other without much rhyme or reason.See next
Generally the differentiation between-coreand-webdoes 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-outputis complicated and not clearly defined in what exactly it is supposed to do. Rethink and rewrite.api-serializeis 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-callandmake-api-callare 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-conditionneeds 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-pagerestart during debugging.Reconsider the role ofredirect. Maybe it should act as areturn-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 inrequestis awful and hard to understand. Rewrite that part completely.requesthas been rewritten.There's probably a lot more still.