used the wrong email address to reply to the mailing list. Here again the Text:
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.
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.
However, just a suggestion :)
Am 05.12.2012 um 15:09 schrieb V.Krishn <vkrishn4_at_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".
> Unsubscribe: alpine-devel+unsubscribe_at_lists.alpinelinux.org
> Help: alpine-devel+help_at_lists.alpinelinux.org
Received on Wed Dec 05 2012 - 17:04:14 GMT
- application/pkcs7-signature attachment: smime.p7s