~alpine/devel

21 11

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

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20121129152317.69585a4f@ncopa-desktop.alpinelinux.org>
Sender timestamp
1354198997
DKIM signature
missing
Download raw message
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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Details
Message ID
<1354214643.44872.YahooMailNeo@web162802.mail.bf1.yahoo.com>
In-Reply-To
<CADVmKVA1suVE3D00pxCzALAqbP3N3aabMsCmWuzMRFmWbP6Zdg@mail.gmail.com> (view parent)
Sender timestamp
1354214643
DKIM signature
missing
Download raw message
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 <jeremy@thomersonfamily.com>
To: Jerry Jacobs <xor.gate.engineering@gmail.com> 
Cc: Der Tiger <der.tiger.alpine@arcor.de>; Natanael Copa <ncopa@alpinelinux.org>; Alpine ACF <acf@lists.alpinelinux.org>; Alpine Developers <alpine-devel@lists.alpinelinux.org> 
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 <xor.gate.engineering@gmail.com> wrote:

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/
>
>
>On 29 November 2012 17:36, Der Tiger <der.tiger.alpine@arcor.de> wrote:
>> 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!
>>
>> Am 2012-11-29 15:23, schrieb Natanael Copa:
>>> 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:  alpine-devel+unsubscribe@lists.alpinelinux.org
>>> Help:         alpine-devel+help@lists.alpinelinux.org
>>> ---
>>>
>>>
>>
>>
>>
>> ---
>> Unsubscribe:  acf+unsubscribe@lists.alpinelinux.org
>> Help:         acf+help@lists.alpinelinux.org
>> ---
>>
>
>
>---
>Unsubscribe:  acf+unsubscribe@lists.alpinelinux.org
>Help:         acf+help@lists.alpinelinux.org
>---
>
>
Details
Message ID
<C4453D93-B8C1-40E9-8DE2-21C595C9F6D1@yahoo.com>
In-Reply-To
<20121129152317.69585a4f@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1354204668
DKIM signature
missing
Download raw message
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@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.

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

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

Ted


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Jeremy Thomerson <jeremy@thomersonfamily.com>
Details
Message ID
<CADVmKVA1suVE3D00pxCzALAqbP3N3aabMsCmWuzMRFmWbP6Zdg@mail.gmail.com>
In-Reply-To
<CA+TFifZsTmWrJ=jSgm5h0Guj4hTBMVbDPka1kCB0zEsmV7DoOQ@mail.gmail.com> (view parent)
Sender timestamp
1354210260
DKIM signature
missing
Download raw message
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 <
xor.gate.engineering@gmail.com> wrote:

> 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/
>
> On 29 November 2012 17:36, Der Tiger <der.tiger.alpine@arcor.de> wrote:
> > 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!
> >
> > Am 2012-11-29 15:23, schrieb Natanael Copa:
> >> 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:  alpine-devel+unsubscribe@lists.alpinelinux.org
> >> Help:         alpine-devel+help@lists.alpinelinux.org
> >> ---
> >>
> >>
> >
> >
> >
> > ---
> > Unsubscribe:  acf+unsubscribe@lists.alpinelinux.org
> > Help:         acf+help@lists.alpinelinux.org
> > ---
> >
>
>
> ---
> Unsubscribe:  acf+unsubscribe@lists.alpinelinux.org
> Help:         acf+help@lists.alpinelinux.org
> ---
>
>

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

Jeremy Thomerson <jeremy@thomersonfamily.com>
Details
Message ID
<CADVmKVDuis5+qsbuJZhSyJ3hyr-hSi_HNbBo2NAPNHsxxFB-2g@mail.gmail.com>
In-Reply-To
<1354214643.44872.YahooMailNeo@web162802.mail.bf1.yahoo.com> (view parent)
Sender timestamp
1354217830
DKIM signature
missing
Download raw message
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 <ttrask01@yahoo.com> 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 <jeremy@thomersonfamily.com>
> *To:* Jerry Jacobs <xor.gate.engineering@gmail.com>
> *Cc:* Der Tiger <der.tiger.alpine@arcor.de>; Natanael Copa <
> ncopa@alpinelinux.org>; Alpine ACF <acf@lists.alpinelinux.org>; Alpine
> Developers <alpine-devel@lists.alpinelinux.org>
> *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 <
> xor.gate.engineering@gmail.com> wrote:
>
> 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/
>
> On 29 November 2012 17:36, Der Tiger <der.tiger.alpine@arcor.de> wrote:
> > 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!
> >
> > Am 2012-11-29 15:23, schrieb Natanael Copa:
> >> 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:  alpine-devel+unsubscribe@lists.alpinelinux.org
> >> Help:         alpine-devel+help@lists.alpinelinux.org
> >> ---
> >>
> >>
> >
> >
> >
> > ---
> > Unsubscribe:  acf+unsubscribe@lists.alpinelinux.org
> > Help:         acf+help@lists.alpinelinux.org
> > ---
> >
>
>
> ---
> Unsubscribe:  acf+unsubscribe@lists.alpinelinux.org
> Help:         acf+help@lists.alpinelinux.org
> ---
>
>
>
>
>

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

Details
Message ID
<CA+TFifa5bR4wEFd5STJ-O9bHSCvQ6gGDaF_fn9iK6Oqb0K5eSQ@mail.gmail.com>
In-Reply-To
<20121129152317.69585a4f@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1354200757
DKIM signature
missing
Download raw message
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 <ncopa@alpinelinux.org> wrote:
> 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:  acf+unsubscribe@lists.alpinelinux.org
> Help:         acf+help@lists.alpinelinux.org
> ---
>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Details
Message ID
<080FA62F-A62B-46D8-8C64-0A91DF5F6C01@yahoo.com>
In-Reply-To
<20121129220245.3b7a6f9f@vostro> (view parent)
Sender timestamp
1354223631
DKIM signature
missing
Download raw message
On Nov 29, 2012, at 3:02 PM, Timo Teras <timo.teras@iki.fi> wrote:

> On Thu, 29 Nov 2012 10:57:48 -0500 Ted Trask <ttrask01@yahoo.com> 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.

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.

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

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

> There are valid reasons for both ways. But they are not just "style
> 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

---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<50B78EF5.6040006@arcor.de>
In-Reply-To
<20121129152317.69585a4f@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1354206965
DKIM signature
missing
Download raw message
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!

Am 2012-11-29 15:23, schrieb Natanael Copa:
> 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:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>
>



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Details
Message ID
<CA+TFifZsTmWrJ=jSgm5h0Guj4hTBMVbDPka1kCB0zEsmV7DoOQ@mail.gmail.com>
In-Reply-To
<50B78EF5.6040006@arcor.de> (view parent)
Sender timestamp
1354210142
DKIM signature
missing
Download raw message
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/

On 29 November 2012 17:36, Der Tiger <der.tiger.alpine@arcor.de> wrote:
> 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!
>
> Am 2012-11-29 15:23, schrieb Natanael Copa:
>> 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:  alpine-devel+unsubscribe@lists.alpinelinux.org
>> Help:         alpine-devel+help@lists.alpinelinux.org
>> ---
>>
>>
>
>
>
> ---
> Unsubscribe:  acf+unsubscribe@lists.alpinelinux.org
> Help:         acf+help@lists.alpinelinux.org
> ---
>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20121129220245.3b7a6f9f@vostro>
In-Reply-To
<C4453D93-B8C1-40E9-8DE2-21C595C9F6D1@yahoo.com> (view parent)
Sender timestamp
1354219365
DKIM signature
missing
Download raw message
On Thu, 29 Nov 2012 10:57:48 -0500 Ted Trask <ttrask01@yahoo.com> 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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20121130154031.0b4de943@ncopa-desktop.alpinelinux.org>
In-Reply-To
<50B78EF5.6040006@arcor.de> (view parent)
Sender timestamp
1354286431
DKIM signature
missing
Download raw message
On Thu, 29 Nov 2012 17:36:05 +0100
Der Tiger <der.tiger.alpine@arcor.de> wrote:

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

Performance is not really what we want to address.
 
> - 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.

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

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.

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

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

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.

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

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

> Personally, I'd prefer a slim, slick and lean HTML-only configuration
> 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
> 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.

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!
 
> Kind Regards, Tiger


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<201212022211.23812.vkrishn4@gmail.com>
In-Reply-To
<20121129152317.69585a4f@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1354466483
DKIM signature
missing
Download raw message
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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Details
Message ID
<201212032356.42772.vkrishn4@gmail.com>
In-Reply-To
<1354214643.44872.YahooMailNeo@web162802.mail.bf1.yahoo.com> (view parent)
Sender timestamp
1354559202
DKIM signature
missing
Download raw message
On Friday, November 30, 2012 12:14:03 AM Ted Trask 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<alpine.LFD.2.02.1212050955390.22932@kunkku.net>
In-Reply-To
<201212022211.23812.vkrishn4@gmail.com> (view parent)
Sender timestamp
1354694229
DKIM signature
missing
Download raw message
On Sun, 2 Dec 2012, V.Krishn wrote:

> 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) ?

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Jeremy Thomerson <jeremy@thomersonfamily.com>
Details
Message ID
<CADVmKVAc5xVsLhCqXwVSuRg-EKwbORkfhOhx+4bucos1FO1BWQ@mail.gmail.com>
In-Reply-To
<50BF7DCB.4040208@arcor.de> (view parent)
Sender timestamp
1354727188
DKIM signature
missing
Download raw message
On Wed, Dec 5, 2012 at 11:00 AM, Der Tiger <der.tiger.alpine@arcor.de>wrote:

> Hi Kaarle,
>
> > 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 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.
>

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.


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

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
Oliver Loch <grimeton@gmx.net>
Details
Message ID
<88399884-A181-4082-A6DF-EEA0B2B374A5@gmx.net>
In-Reply-To
<201212051939.19111.vkrishn4@gmail.com> (view parent)
Sender timestamp
1354723266
DKIM signature
missing
Download raw message
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

Am 05.12.2012 um 15:09 schrieb "V.Krishn" <vkrishn4@gmail.com>:

> On Wednesday, December 05, 2012 01:27:09 PM you wrote:
>> On Sun, 2 Dec 2012, V.Krishn wrote:
>>> 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) ?
>> 
>> 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.
> 
> Having a backed lua framework would be nice.
> Tir could be adopted/modified as a base.
> 
>> 
>> 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.
>> 
> 
> 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
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 
Oliver Loch <o.loch@gmx.net>
Details
Message ID
<0467883F-A7E4-4156-940E-9F5F10AD5FB2@gmx.net>
In-Reply-To
<201212051939.19111.vkrishn4@gmail.com> (view parent)
Sender timestamp
1354723454
DKIM signature
missing
Download raw message
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 ). 

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


Am 05.12.2012 um 15:09 schrieb V.Krishn <vkrishn4@gmail.com>:

> On Wednesday, December 05, 2012 01:27:09 PM you wrote:
>> On Sun, 2 Dec 2012, V.Krishn wrote:
>>> 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) ?
>> 
>> 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.
> 
> Having a backed lua framework would be nice.
> Tir could be adopted/modified as a base.
> 
>> 
>> 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.
>> 
> 
> 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
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 
Details
Message ID
<50BF7DCB.4040208@arcor.de>
In-Reply-To
<alpine.LFD.2.02.1212050955390.22932@kunkku.net> (view parent)
Sender timestamp
1354726859
DKIM signature
missing
Download raw message
Hi Kaarle,

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<201212051939.19111.vkrishn4@gmail.com>
In-Reply-To
<alpine.LFD.2.02.1212050955390.22932@kunkku.net> (view parent)
Sender timestamp
1354716559
DKIM signature
missing
Download raw message
On Wednesday, December 05, 2012 01:27:09 PM you wrote:
> On Sun, 2 Dec 2012, V.Krishn wrote:
> > 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) ?
> 
> 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.

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

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

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<alpine.LFD.2.02.1212081711140.8590@kunkku.net>
In-Reply-To
<0467883F-A7E4-4156-940E-9F5F10AD5FB2@gmx.net> (view parent)
Sender timestamp
1354986172
DKIM signature
missing
Download raw message
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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Details
Message ID
<201212082337.52917.vkrishn4@gmail.com>
In-Reply-To
<alpine.LFD.2.02.1212081711140.8590@kunkku.net> (view parent)
Sender timestamp
1354990072
DKIM signature
missing
Download raw message
On Saturday, December 08, 2012 10:32:52 PM you wrote:

> Some ACF use cases require streaming status information back to the client
> 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
> 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,

Does this mean kinda  web pub/sub system?

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

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<CAFivhP=8QKAZ5YwDkND8=L3B4pzzr_ny1fX16kaSRRnawyw=NQ@mail.gmail.com>
In-Reply-To
<20121129152317.69585a4f@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1358677793
DKIM signature
missing
Download raw message
I hope it's OK to be so late on the thread...

2012/11/29 Natanael Copa <ncopa@alpinelinux.org>

> 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.
>
>
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
Reply to thread Export thread (mbox)