[Opa] Enterprise, HTML, Authentication, MVC and more

TJ opa at iam.tj
Wed Jan 30 17:48:07 UTC 2013


I'm currently evaluating Opa's suitability for developing web-based applications for medium and large Enterprises with well-defined formal
development methodologies and processes. I wonder if MLstate could address the following observations and questions. Thanks in advance.

Some of the attractive features are:

 * type-checking
 * single language on client and server
 * inference of client server separation
 * harnessing existing platforms and libraries (e.g. node.js, jquery)
 * seems to offer considerable reduction of development complexity for client-server applications.

During my early research I've identified some key concerns that despite extensive efforts I've been unable to find answers to.

1. What seems to be lacking is comprehensive documentation for much of the API and some parts of the language. CONTRIBUTING.md stresses the importance of documenting the
code to support opadoc but the existing code-base seems to ignore that - not a good example, and needlessly puts the new-entry barrier much higher than
it needs to be. See, for example, stdlib.core.xhtml.dom_element and stdlib.core.xhtml.Dom.get_text.

Note: CONTRIBUTING.md says "For an example of documentation, see DOCUMENTING, in this directory, or see all the existing documentation." ... but there
is no DOCUMENTING file.

The language definition is hazy. For operator precedence "The priority and associativity of the operators is based on the leading characters of the operator" seems somewhat obtuse and doesn't clearly
define how custom operator precedence is determined - especially if their leading characters aren't in the table shown in the core documentation. It also doesn't make clear what \| is.

These omissions and inconsistencies quickly develop a lack of confidence since they damage the authority such documentation should have.

2. The advertising claims native support for HTML 5 but the libraries seem focused on XHTML or XML. stdlib.web.canvas contains representations of some media elements but there is no comprehensive
HTML5 model as there is for XML/XHTML, and stdlib.web.Template claims to be for parsing XML into XHTML. There seems no easy way to ensure that the output can be validated against the standards or to
specify which DTD or schema is to be used.

3. What support is there for authentication schemes: digest, basic, etc? stdlib.components.login.CLogin appears to handle log-ins from custom forms but there is no mention of the authentication schemes.

4. For HTTPS the documentation doesn't indicate which protocol (SSL/TLS) and version the server can/will offer to clients, and there doesn't seem to be a way to specify client certificates.

5. node.js supports SSL/TLS NPN and SNI services but there is no indication of how these can be used in Opa. stdlib.core.web.server.Server_options.default_https_options doesn't give any hints.

6. IPv6 support? I see stdlib.core.web.core.IPv4 but no mention of IPv6.

7. The harnessing of the node.js framework is a good thing. However, what happens when node.js itself is updated (CVE patches for example). How quickly can patches be applied to
production deployments? This applies to other libraries that Opa harnesses, too.

8. Several external service APIs are baked into the standard library. What happens when those APIs are changed? Production deployments may be left hanging waiting for MLState
to update the stdlib implementation. This is a major risk for any organisation deploying Opa especially where changes have to be internally reviewed and approved before being
deployed to production.

9. Views. In all the example code the View is Opa source-code with a mix of functional language and X(H)TML text strings. What concerns me in particular is
this hard-coding of the HTML elements. What I expected to see was a clean separation of (X)HTML view templates from code, with insertion of dynamic elements and content through
utilising the DOM (client or server-side, depending on context). E.g:

<html>
 <head>
  <title id="custom_title"></title>
 </head>
 <body>
  <h1 id="custom_title_page"></h1>
 </body>
</html>

And in the view source-code something along the lines of:

custom_title = "Hello World Example";
document.title = custom_title;
document.getElementById('custom_title_page').innerHTML = custom_title;

Instead it seems that Opa takes backward steps in managing (X)HTML elements as text strings with no object-oriented representation - which the DOM should provide on client
and server-side. Is it possible to use DOM objects to completely model the view?


More information about the Opa mailing list