The proposed ACF2 seems to be a complete redesign to move from functional to data-driven design. Unfortunately, the doc does not give any reasons why this change is desired. What is the benefit? This change does not address any of the goals listed below. Just as a style preference, I've always been a C/functional design guy, rather than C++/object-oriented guy. I find object-oriented design more difficult to read and debug.
See further comments below.
On Nov 29, 2012, at 9:23 AM, Natanael Copa <ncopa_at_alpinelinux.org> wrote:
> Some of the goals:
> * better security design
What is wrong with the security of the existing ACF? What would you do differently?
> * remove unnecessary complexity from modules
Can you give an example of the "unnecessary complexity" in the current ACF modules?
> * organize the libs better
While I agree that the libs could be organized and, especially, documented better, what is the actual proposal here? There is nothing in the doc.
> * fix concurrency - no race conditions
This is a legitimate concern in the current ACF. The problem can be managed, not solved, with a daemon in the same manner as proposed for ACF2. However, there is nothing to prevent two users from overwriting each other's work.
> * improve CLI interface
I have done quite a bit of work for acf-core-0.15 to split out the web interface from the ACF core. As far as I can tell, there is now nothing preventing us from creating a functional CLI interface for ACF.
I don't agree that "The full client-side approach eliminates all possible HTML-related security vulnerabilities". There is still a web server accepting the same requests. Nothing prevents a malicious user from directly accessing it.
I do agree that a single-page application has some advantages in user experience. However, there is nothing preventing us from creating a single-page application based on the current ACF. Any action can return it's result as JSON or as HTML without the surrounding skin/template.
> For web frontend we have been talking of using existing frameworks like
> Backbone.js and RequireJS. For backend we have been talking about using
> things like augeas and using Lua tables to create data models.
I have known about augeas for some time, and there is nothing preventing us from using it with the current ACF. However, I have not felt the need to, because I have not created an ACF recently that could benefit from it. The existing ACF modules are working, so I have not felt the need to rewrite them.
This seems a good place to talk a bit more about the data-driven design, because augeas seems to be the genesis of the idea. While augeas allows you to modify the config files more safely, since it ensures the syntax is correct, I think it is better suited as a backend underneath a functional front end.
The augeas.net/tour.html page gives the simple example of adding an entry to the hosts file. The augeas user must know that a new entry can be added under /files/etc/hosts/ and that it should have values for ipaddr, canonical, and alias. Isn't it easier to see a web page with an "Add entry" button and an appropriate form? How can you automatically generate that button and form based upon the augeas output? I think you would end up having to code the button and form into the model/view, which means you're going back to the functional design of ACF.
I see no benefit to the data-driven design when it comes to a user-facing application.
> This will require some massive work but I think we can do it. Hopefully
> it will be simpler to write models once the basic framework is in place.
I think it's pretty easy to write ACF modules.
As stated above, I think you would end up having to do the same work in ACF2 in order to get a user-friendly interface.
Sorry if the above sounds like a rant, but I legitimately don't understand the benefits of the proposal.
Received on Thu Nov 29 2012 - 10:57:48 UTC