Re: Proposed architecture for future versions: dispatch tables for entry points

Hi Chris,,

Not sure I will have time to tackle this for 1.5 but wanted to float the idea. I might have time to tackle this for the rest handler.

Right now the code uses the symbol table as a dispatch table for incoming requests. While this is simple it is also very leaky in terms of technology, so you get to specify which subroutine you start in, and this can have security considerations if a module has private methods for things like helper functions.

Agreed. Our current situation assumes that every function accessible in a certain module/script provides functionality that should be externally available. I've wondered more than once if this is really desirable, yet did't figure it was high enough priority to work on, since it would require a lot of code churn and intimate knowledge of all parts of the application. As your paragraph above suggests: this may not actually be true.

I would like to suggest we move to a more resource-oriented URL structure and use a dispatch table to do it. In other words instead of subroutines, we'd have a hash of hashrefs, which would all provide coderefs for actions.

Would this also allow for the company to become part of the URL so we can have a per-company cookie and thus per-company logins? If it does (and I think that's the case), can we take that as a requirement as part of the design?

What do folks think?

I think it's a good idea, but like the move to Dancer, I think it's something to be done gradually and as part of restructuring that's going on anyway, which assures we use our energy efficiently and effectively.

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.