[Opa] Enterprise, HTML, Authentication, MVC and more
henri.binsztok at gmail.com
Thu Jan 31 21:07:47 UTC 2013
Thanks for your detailed feedback on Opa. Please find some answers below.
> 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 guidelines are in place exactly to improve the documentation from
now on. This is also the reason why, for instance, we moved most of
the documentation to GitHub wiki and made it editable by every
The API documentation is still a work in progress and we consider
adding wiki-like capability to http://doc.opalang.org.
> 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.
The Opa parser is built on PEGs, and this part of the documentation
(editable) just intends to explain that.
> 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.
Opa was indeed originally developed for XHTML, and HTML5 features
should keep up pretty quickly. Support for full W3C spec is indeed
welcome. Any contribution will be greatly appreciated.
> 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.
HTML auth is rarely used for web apps, and not yet present in Opa. cf.
> 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.
Opa currently supports SSL and client certificates are not yet
managed. Adding support is pretty easy though.
> 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.
Adding bindings to Opa from Node is getting easier with the latest
releases of Opa (> 1.1.0). Expect a blog post soon explaining that.
> 6. IPv6 support? I see stdlib.core.web.core.IPv4 but no mention of IPv6.
IPv6 is not yet supported. But again, it's contribution that would be welcome.
> 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.
Opa is a compiler which does not touch the runtime (anymore). Unless
some vulnerable pattern would be found in the generated code, the code
that the Opa compiler generates should not be affected by Node
> 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.
I would not call that a major risk, especially as you can help us in
contributing patches to the APIs in the standard library. In the long
run, we can built a central repository of Opa packages and have each
> 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:
> <title id="custom_title"></title>
> <h1 id="custom_title_page"></h1>
> 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?
You can do MVC in Opa. In fact, Opa does not enforce any style of
programming, so you are maybe too free in your programming patterns
We will publish a book with O'Reilly that is in production right now
and should be released at the end of the month. Expect it to be a good
introduction to the Opa programming style.
> Opa mailing list
> Opa at lists.owasp.org
More information about the Opa