Subject: [alpine-devel] Ideas for a new config framework, ACF2

From: Natanael Copa <[email-masked]>
Date: Thu, 29 Nov 2012 15:23:17 +0100

Hi,

Me and Kaarle have been playing with the idea "what if we started with
ACF from scratch today, how would it be?".

We collected some ideas and have now come up with a fairly detailed
plan for an ACF2.

Some of the goals:
* better security design
* remove unnecessary complexity from modules
* organize the libs better
* fix concurrency - no race conditions
* improve CLI interface
* modernize web GUI (write the gui in javascript)

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.

Kaarle has written are more detailed plan: http://www.datakunkku.fi/acf/

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.

What do you think?

-nc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Ted Trask <[email-masked]>
Date: Thu, 29 Nov 2012 10:57:48 -0500

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.

> * 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.

> * modernize web GUI (write the gui in javascript)

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.

> 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.

> 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.

Ted

---

---

From: Timo Teras <[email-masked]>
Date: Thu, 29 Nov 2012 22:02:45 +0200

On Thu, 29 Nov 2012 10:57:48 -0500 Ted Trask <[email-masked]> wrote:

> 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.

I would recommend you trying one declarative language before condemning
the programming paradigm.

See:
http://en.wikipedia.org/wiki/Declarative_programming
http://en.wikipedia.org/wiki/Comparison_of_programming_paradigms

Curiously - all new GUI languages are declarative by nature. QT has QML,
Microsoft did XAML, etc. Having tried both before mentioned languages along
with the traditional imperative GUI toolkits (e.g. MFC, GTK, wxWidgets,
Qt/classes). I have to admit that I see the benefit of declarative
paradigm for UI use.

Though, ACF is ultimately about configuration management, which to my
first impression is pure data modelling problem. And as such, I would
be tempted at least see how the data-driven model looks like.

All problems are solveable with any programming paradigm. But if you
choose the correct programming paradigm for your problem, you end up
writing less code, less bugs, and have less maintenance overhead.

One practical example: there was recent changes in ACF on 2.4->2.5 - and
I actually had to spend 8 hours fixing my two simple ACF modules because
the core libraries got changed in ways that appear only imperative
programming - problem which would not have appeared if ACF was
declarative.

There are valid reasons for both ways. But they are not just "style
issues". Please try some declaritive language to see how they work.

- Timo

---

---

From: Ted Trask <[email-masked]>
Date: Thu, 29 Nov 2012 16:13:51 -0500

> the programming paradigm.

I suppose I left myself open for that one. Note to self: never state style preferences.

Please don't interpret a preference as condemning all other options.

> programming - problem which would not have appeared if ACF was

Sorry about that. Although I would blame it on iterative design and changing requirements, which is a problem regardless of programming paradigm.

> issues". Please try some declaritive language to see how they work.

Can you state some of the valid reasons for the ACF2 design?

Remember, my concern is not whether or not ACF2 can be done, but whether or not it is worth the "massive work" mentioned by ncopa. If I'm going to do "massive work", I want to see some benefit. Changing programming paradigms does not count as a benefit in my book.

Ted

---

---

From: Jerry Jacobs <[email-masked]>
Date: Thu, 29 Nov 2012 15:52:37 +0100

Hi Guys,

As i'm mostly a debian user I still like the ACF framework and kind of
works on debian. I created some modules for it (apache2, paco, dpkg,
git) and was not that hard. It would be nice to see the ACF2 framework
also not to distro-centric where possible. Of course Alpine has a
lightweight philosophy. Maybe you could consider like before a
"baselayout" which is distro-centric. Then people can branch this repo
and create there own.

When the framework is rewritten it should be as pluggable as possible
and with documentation and examples which is currently missing.

There is also another nice javascript project:
http://silkjs.net and another Lua-like (based) lightweight programming
language http://www.squirrel-lang.org which could be considered.

Kind regards,
Jerry
- http://xor-gate.org

On 29 November 2012 15:23, Natanael Copa <[email-masked]> wrote:
> Unsubscribe:  [email-masked]
> Help:         [email-masked]
> ---
>

---

---

From: Der Tiger <[email-masked]>
Date: Thu, 29 Nov 2012 17:36:05 +0100

Hi Natanael,
Hi Kaarle,

Thanks for the comprehensive project plan! I fully agree, the current
ACF is good work, but needs overhauling, due to the problems stated in
the proposal. At this stage, I am just not sure if using JavaScript and
introducing client-side GUIs would be wise choices.

- ACF is a configuration framework. IMHO, the configuration of most
Alpine systems is usually done by a single admin or at least a small
number of admins, who usually won't do administration work on a single
machine, simultaneously. Therefore, there is no significant server
performance benefit to be expected from outsourcing HTML page formatting
to the client side. ACF is not a "common user" interface.

- Using JavaScript would introduce another programming language required
besides shell scripting and LUA to write ACF applications and modules.
Not every programmer interested in Alpine Linux is capable or willing to
handle an extensive number of programming languages in order to write
packages for Alpine Linux. The higher the required number of languages,
the fewer the number of people able and willing to contribute.

- JavaScript is considered by all internet security majors to be a
potential security risk. This is not only due to security bugs in
various browsers (e.g. Chrome), but also due to the complexity of
JavaScript interaction with servers. Most companies filter JavaScript in
their local nets and allow it only on secure channels between clients
and the internet in order to make some websites work, where there is no
alternative method available than a client script (e.g. large volume
data browsing). Using JavaScript for configuration of a local
environment does compromise this security strategy.

- JavaScript adds complexity to the HTML page transmitted and displayed.
It is likely, there are devices like PDAs or mobile phones, that won't
be able to handle certain JavaScript initiated reformatting of web pages
correctly. Admins do frequently use PDAs to reconfigure their servers
and routers or to look up some configuration on these devices. Also
there is the issue of DHTML incompatibilities between browsers.

- KISS [1], as you certainly know. The more components are required for
the ACF to work, the higher the risk the next update will render the
system inoperable. And there are already JSON, LUA, minihttpd and
various other components involved.

I, admittedly, do have strong reservations regarding both, Java and
JavaScript. A co-worker once eloquently put it to: "Java and JavaScript
in 99% of all cases are used by programmers to work around problems,
they either don't understand or don't care to solve properly." I've
largely experienced this to be true.

Personally, I'd prefer a slim, slick and lean HTML-only configuration
GUI with pages generated by the host rather than the client. But than
again, I'm just an old f@rt, who has no appreciation for "modern",
blinking, multi-layered and high colour pop-up interfaces, that are as
slow as a snail and close to indistinguishable from any given first
person shooter action game.

Kind Regards, Tiger

[1] KISS = Keep it simple, stupid!

---

---

From: Jerry Jacobs <[email-masked]>
Date: Thu, 29 Nov 2012 18:29:02 +0100

As a theme suggestion if people didn't already know the sleek and nice
organised Twitter Bootstrap which saves the clutter from re-inventing
the wheel again:

http://twitter.github.com/bootstrap/

---

---

From: Jeremy Thomerson <[email-masked]>
Date: Thu, 29 Nov 2012 11:31:00 -0600

I second the nomination for using Bootstrap for the HTML layout.  I'd
highly recommend a responsive layout for management from mobile devices as
well.

---

From: Ted Trask <[email-masked]>
Date: Thu, 29 Nov 2012 10:44:03 -0800 (PST)

As part of the design of ACF, we have tried to keep it as simple as possible, so as to be compatible with as many browsers as possible. So, we have not used HTML5 or relied on javascript (as much as possible). Bootstrap relies on HTML5 and javascript, so I'm hesitant to include it. What makes Bootstrap appealing? Is it simply the responsive layout for mobile devices?

>From a technical standpoint, I'm not opposed to including it in a skin, just not in the core. I would like to keep the generated HTML as clean as possible, and allow skins to extend the functionality.

V.Krishn had proposed creating a skin with the jquery-mobile framework (http://jquerymobile.com/) for similar reasons of usability on mobile devices. He had made some progress, but he required changes to the ACF code to clean up the generated HTML. zelebar and I have also talked about cleaning up the HTML output, but have been too busy to make much progress. Hopefully it would be ready for Alpine Linux 2.6.

Ted

________________________________
 From: Jeremy Thomerson <[email-masked]>
To: Jerry Jacobs <[email-masked]> 
Cc: Der Tiger <[email-masked]>; Natanael Copa <[email-masked]>; Alpine ACF <[email-masked]>; Alpine Developers <[email-masked]> 
Sent: Thursday, November 29, 2012 12:31 PM
Subject: Re: [acf] Re: [alpine-devel] Ideas for a new config framework, ACF2

I second the nomination for using Bootstrap for the HTML layout.  I'd highly recommend a responsive layout for management from mobile devices as well.

On Thu, Nov 29, 2012 at 11:29 AM, Jerry Jacobs <[email-masked]> wrote:

---

From: Jeremy Thomerson <[email-masked]>
Date: Thu, 29 Nov 2012 13:37:10 -0600

Bootstrap and other modern HTML techniques, used correctly, support many
more legacy browsers than 'plain HTML'.  They also make it easy to make
things visually attractive, something that we as developers are admittedly
generally poor at accomplishing.  Add to that the reflowing of content
across various sizes of device and there are many advantages to using
modern HTML frameworks.

Jeremy

On Thu, Nov 29, 2012 at 12:44 PM, Ted Trask <[email-masked]> wrote:

> As part of the design of ACF, we have tried to keep it as simple as
> possible, so as to be compatible with as many browsers as possible. So, we
> have not used HTML5 or relied on javascript (as much as possible).
> Bootstrap relies on HTML5 and javascript, so I'm hesitant to include it.
> What makes Bootstrap appealing? Is it simply the responsive layout for
> mobile devices?
>
> From a technical standpoint, I'm not opposed to including it in a skin,
> just not in the core. I would like to keep the generated HTML as clean as
> possible, and allow skins to extend the functionality.
>
> V.Krishn had proposed creating a skin with the jquery-mobile framework (
> http://jquerymobile.com/) for similar reasons of usability on mobile
> devices. He had made some progress, but he required changes to the ACF code
> to clean up the generated HTML. zelebar and I have also talked about
> cleaning up the HTML output, but have been too busy to make much progress.
> Hopefully it would be ready for Alpine Linux 2.6.
>
> Ted
>
>   ------------------------------
> *From:* Jeremy Thomerson <[email-masked]>
> *To:* Jerry Jacobs <[email-masked]>
> *Cc:* Der Tiger <[email-masked]>; Natanael Copa <
> [email-masked]>; Alpine ACF <[email-masked]>; Alpine
> Developers <[email-masked]>
> *Sent:* Thursday, November 29, 2012 12:31 PM
> *Subject:* Re: [acf] Re: [alpine-devel] Ideas for a new config framework,
> ACF2
>

---

From: "V.Krishn" <[email-masked]>
Date: Mon, 3 Dec 2012 23:56:42 +0530

On Friday, November 30, 2012 12:14:03 AM Ted Trask wrote:
> V.Krishn had proposed creating a skin with the jquery-mobile framework
> (http://jquerymobile.com/) for similar reasons of usability on mobile
> devices. He had made some progress, but he required changes to the ACF
> code to clean up the generated HTML. zelebar and I have also talked about

To get a feel of it, 
I have experimental acf packages + skin using jquery-mobile framework at: 
http://download.tuxfamily.org/pmreader/alpine/edge/testing/x86/

Script to install in clean alpine v2.4x is here:
http://download.tuxfamily.org/pmreader/alpine/set-acf-alpine-v2.4.sh

-- 
Regards.
V.Krishn

---

---

From: Natanael Copa <[email-masked]>
Date: Fri, 30 Nov 2012 15:40:31 +0100

On Thu, 29 Nov 2012 17:36:05 +0100

> to the client side. ACF is not a "common user" interface.

Performance is not really what we want to address.
 
> the fewer the number of people able and willing to contribute.

Yes, but what if you want contribute with your GUI expertise, know html
and javascript, but have no idea of Lua, nor any interest in it?

By separating the backend from the GUI you can contribute with one of
the parts without knowing the other. You can contribute with Lua
backend and let the GUI ppl do the GUI.
 
> environment does compromise this security strategy.

I don't think we want any javascript on server. But you do have a point
that we need to also think about the client security.

> there is the issue of DHTML incompatibilities between browsers.

I think all smartphones today supports javascript? When we started with
ACF there was a discussion about using javascript and ajax. (web 2.0
was a hot topic at that time). Back then we decided to not use it and
we wanted it to be able to run on any without javascript. Some
javascript was bolted on later.

I think that the world looks different today than it did back then and
now is the time to embrace javascript - for client only.
 
> various other components involved.

Well, part of the motivation for the rewrite is to have it more
modularized with clean and well defined APIs so that you can change
components without breaking stuff.

> largely experienced this to be true.

Java is completely out of the question. I believe that javascript has
its place - for the GUI.

> GUI with pages generated by the host rather than the client. 

I think that a page with multiple http requests for each component,
while still easliy being slow, adds value in form of separation. The
backend will not need to worry about html. Each request ask for smaller
pieces. Makes it easier to do privilege separation.

> But than

To be honest, I think the value of experience is often underestimated
and I hope we don't get blinking multi-layered and high color pop-up
html5 interface that is slow as a snail :)

Thanks for your feedback!

---

---

From: "V.Krishn" <[email-masked]>
Date: Sun, 2 Dec 2012 22:11:23 +0530

Hi,
The "Overhaul of ACF Architecture" look great.

Can we know what frameworks/components are involved.
Few that I could get from the thread:
1. bootstrap
2. backbonejs, requirejs 
3. lua
4. minihttpd
5. json libs
6. sqlite
7. augeas

Any thoughts on tir (lua+mongrel2+zeromq) ?

Having augeas would be nice.

-- 
Regards.
V.Krishn

---

---

From: Kaarle Ritvanen <[email-masked]>
Date: Wed, 5 Dec 2012 09:57:09 +0200 (EET)

> Any thoughts on tir (lua+mongrel2+zeromq) ?

I used Tir as part of the first prototype before writing the
proposal. This was in May, but afterward we decided to opt for full
client-side implementation for the web UI, whereas Tir seems to target
server-side web applications. Even for those, the value add was rather
thin, which is quite natural because the author advertises to use only
1300 lines of code.

The proposal mentions Backbone.js, but after a second prototyping
round I feel that this library creates more problems than provides
solutions, at least in this context. Backbone's data model is rather
limited in comparison to what is proposed for the new ACF. For
example, Backbone does not support nested collections or collections
of primitive types. Circumventing these limitations provided to add
too much complexity both to the server and client implementation.

As much as I dislike JavaScript as a programming language, I still
think it is the best choice for client implementation. Virtually all
devices support JavaScript nowadays, and there are lots of tools which
we can leverage in our implementation. The selection of Lua tools in
this domain is rather modest in comparison, so the KISS principle is
probably better realized with JavaScript.

BR,
Kaarle

---

---

From: "V.Krishn" <[email-masked]>
Date: Wed, 5 Dec 2012 19:39:19 +0530

> thin, which is quite natural because the author advertises to use only

Having a backed lua framework would be nice.
Tir could be adopted/modified as a base.

> too much complexity both to the server and client implementation.

Choice of client-side js libs should not be a stress here.
Rather module-specific adoption of other libs should be possible.

Mongrel2 also involves zeromq, which has its own benefits.

Also to be evaluated for tools/system to be used in ACF2 is "redis".

-- 
Regards.
V.Krishn

---

---

From: Oliver Loch <[email-masked]>
Date: Wed, 5 Dec 2012 17:01:06 +0100

Hi,

have a look at the FreeNAS WebUI. They used Django ( https://www.djangoproject.com/ ) together with DoJo ( http://www.dojotoolkit.org ). 

If we use this setup we get a lot of stuff already working:

On the Django site, as the backend:

- Abstraction on multiple layers.  - There is no need to deal with the database backend. One defines types, and then uses them. Database layer is completely transparent.
- The main code that does everything is written as a module, that is then executed by Django for us. No need to write all the stuff around it.
- Views - every "module" also has views, which are used to generate the page shown to the user. It has a small language to be able to put the values in the right places.
- Every module that is written for Django, has it's own Types+Database, it's own main code and it's own views. It resides in it's own directory and does not interfere with any other plugin. Which breaks only the plugin and not the whole setup.
- It has it's own, builtin, webserver. It's not recommended for production use, but it's there ;) We could also run it as an FCGI backend connected to busybox' httpd.

With DoJo on the client side we get a fully working javascript framework that is know to work in Internet Explorer, Firefox, Chrome, Safari and Opera. We don't have to deal with anything on the client side. Only define the website, get the data in there and that's it. It also offers different GUIs for mobile devices like IPad, iPhone, Android, Windows Mobile and so on... So whatever we hit - it will work ;)

And it has a lot of nice plugins and views. Check out the website at www.dojotoolkit.org

There is even a Djang-DoJo Distribution, but it hasn't been update for a longer time, so imho we should do it on our own.

We can provide a working environment that nearly fits all needs to any plugin developer which can make the Distro become popular for embedded devices and such :)

But there are also downsides:

- Django is written in Python... Maybe there is something similar written in Perl/Lua/Tcl/$Poison.
- The size of Python is really big imho and I don't know if it works with embedded Python.
- The javascript framework can produce a lot of load at the client if we do nasty things like on-the-fly search updates and stuff.

However, just a suggestion :)

KR,

Oliver

---

From: Oliver Loch <[email-masked]>
Date: Wed, 5 Dec 2012 17:04:14 +0100

Hi,

used the wrong email address to reply to the mailing list. Here again the Text:

Hi,

have a look at the FreeNAS WebUI. They used Django ( https://www.djangoproject.com/ ) together with DoJo (http://www.dojotoolkit.org ). 

KR,

Oliver

---

From: Kaarle Ritvanen <[email-masked]>
Date: Sat, 8 Dec 2012 19:02:52 +0200 (EET)

On Wed, 5 Dec 2012, Oliver Loch wrote:

> have a look at the FreeNAS WebUI. They used Django 
> ( https://www.djangoproject.com/ ) together with DoJo 
> (http://www.dojotoolkit.org ).

Django is a very nice framework for web applications. To be frank, several 
aspects in our architecture proposal were influenced by some elegant 
design choices in Django. However, there are several reasons for not using 
Django as part of ACF. As you mentioned, one of them is the large 
footprint. The basic Python and Django packages have a combined footprint 
of 40 megabytes on my Fedora machine, but this is not the only downside.

You wrote that Django makes database access completely transparent. This 
is true to the extent that you don't need to deal with SQL statements, but 
the fact is that Django is tied to SQL databases only. If you look at 
Django's model API, it is quite evident that you really cannot enhance it 
to support non-relational backends.

There are some relatively small SQL databases, such as SQLite (used by 
FreeNAS, 716 kilobytes on my machine), but this is not the main issue with 
SQL. Most Linux applications read their configuration from files in /etc, 
not from an SQL database, which means that you need to generate the files 
from the database contents. I am not impressed at all about the way chosen 
by FreeNAS developers. They have included the generation code into the 
init script of each service (in /etc/rc.d). Embedding SQL queries and 
configuration file blocks to shell scripts is not nice in my opinion.

Were I to design a Django-based configuration system, I would probably use 
Django's template system to generate the files. (The template language is 
not constrained to HTML, even though that's the typical use case.) 
Nevertheless, we can do better with the proposed design for ACF. The 
design is not limited to SQL but can also use e.g. Augeas as a storage 
backend. Augeas implements a bidirectional translation between a 
configuration file and a tree-structured data model, allowing the user to 
directly edit the native configuration files of services. Without a 
bidirectional translation, your manual changes would be overwritten by the 
configuration system. This would be very annoying e.g. when for some 
reason the system does not support the option you need.

Comparing with the architecure we proposed, Django is also inferior with 
respect to handling concurrent changes. If enabled, Django's transaction 
middleware ensures that all database requests related to a single HTTP 
request fall into a single database transaction. This is not sufficient to 
prevent loss of changes when two users edit the same data. There is an 
add-on package called django-locking, but it is not really transparent to 
module developers if multiple model instances are involved in the 
transaction. In contrast, we propose a protection mechanism which is 
completely transparent to module developers.

Some ACF use cases require streaming status information back to the client 
as the operation progresses. Django does not support this very well, at 
least in any production release. (Version 1.5 will have 
StreamingHttpResponse class.)

Finally, remember that Django is a framework intended for implementing 
relational database-oriented web applications with server-side HTML 
templating. While it would be possible to implement CLI and SNMP 
interfaces for Django models, the framework does not really help in that 
effort. We also want to include dynamic state information e.g. from /proc, 
but Django does not help there at all. I think it is better to design the 
framework to take these use cases into account at model API level. As I 
said, Django is a nice framework for the purposes it was designed to and 
obviously has been developed by smart programmers. We will indeed let its 
design influence ours. Even if we decide to implement the web interface as 
a single page application (in JavaScript), we can apply some principles 
found e.g. in Django's form API. We should also take a look at Dojo 
Toolkit.

BR,
Kaarle

---

---

From: "V.Krishn" <[email-masked]>
Date: Sat, 8 Dec 2012 23:37:52 +0530

On Saturday, December 08, 2012 10:32:52 PM you wrote:

> as the operation progresses. 

Thinking of "streaming status information" would it good idea to de-couple 
ACF's streaming part info into AMF (Alpine Monitoring Framework) ?

> Django does not support this very well, at

Does this mean kinda  web pub/sub system?

> found e.g. in Django's form API. We should also take a look at Dojo

On whole I think having a light weight system not tied to one scripting 
language should be good choice.

Choice of persistence manager should be such that any binding with other web 
framework/scripting language be possible.
Eg.  ACF - lua
       AMF - php

Just a thought.

-- 
Regards.
V.Krishn

---

---

From: Der Tiger <[email-masked]>
Date: Wed, 05 Dec 2012 18:00:59 +0100

Hi Kaarle,

> we can leverage in our implementation.
The problem with a client implementation and mobile devices won't be so
much compatibility, but performance. PDAs and Tablets still don't offer
a lot of cpu power, while the OS and the browser software itself often
use up most of the available resources. Soon, the JavaScript client
software is likely to hit a performance wall on those devices, when the
complexity of the client software increases with functionality.

I can't help myself, but with all that has been written, I still don't
see the benefit of a strict client implementation over a JavaScript-free
host implementation. You and Nathanael, on the other hand, seem to be
quite set on advocating your proposal. Well, I suppose you've thought it
through.

Best Regards, Tiger

---

---

From: Jeremy Thomerson <[email-masked]>
Date: Wed, 5 Dec 2012 11:06:28 -0600

> complexity of the client software increases with functionality.

Not true with most modern smart phones.  If you're still using a
Blackberry, then yes - perhaps.  But most smart phones now are better than
the best laptops three years ago.

> quite set on advocating your proposal. Well, I suppose you've thought it

For many years I have been an advocate of making sites that work with or
without JS (incremental improvements).  However, nowadays this is not
strictly necessary, and for a niche market like server admins using Alpine
/ ACF you can set your own browser requirements without many ramifications.

Regards,
JT

---

From: Florian Heigl <[email-masked]>
Date: Sun, 20 Jan 2013 12:29:53 +0200

I hope it's OK to be so late on the thread...

2012/11/29 Natanael Copa <[email-masked]>

> We collected some ideas and have now come up with a fairly detailed
One of my first questions regarding ACF was if it supported managing
multiple servers (that have ACF configured) from one console.
Maybe you can discuss it for a moment when you next look at ACF2 ideas. I
think in the "free" world only m0n0wall ever had that feature, but since it
came to my mind very early I think it's something that many people would
enjoy.

Greets
Florian