On 27/08/17 19:37, Chris Travers wrote:
To be honest, I don't think we should be splitting either of these out. Especially at this stage.
Neither of them is a significant quantity of code, and what code there is, is specific to the way we use them.
I believe that most, if not all CGI assumptions have already been removed, and if they haven't should be fairly easily removed once identified.
Can you please show some examples of the CGI assumptions that we are still making.
I know there are some still present in the Legacy code, but that's been wrapped at a higher level so it doesn't impact the rest of the codebase.
I really don't believe it is a sane thing to "hack" in any sort of api/plugin layer right now.
If you have followed the discussion on #ledgersmb you will have noticed that there has been a lot of general discussion (and some on the dev list as well) about designing an API.
I STRONGLY believe that we need to DESIGN the API before ANY code is written.
To do otherwise is counterproductive, and a waste of everyone's time.
You only have to look at the current situation where we have a partial implementation of a perl API, some completely disparate http api like functions, and at least two "API subprojects/libraries"
All of the above are only a tiny portion of what is needed, none of them have even remotely similar interfaces, and as of right now, I don't believe any of them are remotely maintainable in the long term.
They certainly aren't useful beyond the original intent they were created against.
To work towards being ready to start coding for an API we need to....
- Design the API (a lot has been done towards this, but there is a lot more to be done. Many of the notes are in a wiki document on our github repo)
- Document the API endpoints in an industry standard way. (I'm partial to swagger, but it's not the only option)
- Decide on the implementation framework and other technologies to be used for implementing the API (Dancer may be specified here, but there definitely other options)
- Finally get public comment on the design.
ONLY once we have covered all of the above, should we be writing ANY API code.
We don't need to fully design every endpoint first, but we do need to define the API structure, and sufficient endpoints to make some example functionality viable and testable.
Additional endpoints can then be defined following that structure.
I wouldn't like to see that happen right now, as most of the CGI specific code should only be within the legacy codebase, and we have a declared freeze on the legacy codebase for general changes.
Also, I don't think we should make any changes to the templating / reporting mechanism until we have a properly designed API in place, as the correct way to implement any changes here would be to do it right in the API, then implement the client side as an API consumer.
In short, my thoughts are, don't do it until we have a properly designed API
_______________________________________________ devel mailing list ..hidden.. https://lists.ledgersmb.org/mailman/listinfo/devel