Keplerizing eLua
Locked
|
Hello list,
eLua offers an HTTP webserver as one of it's examples (lhttpd.lua). This means there is whole new dimension of applications, not always well known by us "ordinary" embedded developers, to be offered as web-services, web-service clients and distributed web aplications. Kepler (www.keplerproject.org) is "the Lua way of doing web" :) (it is actually one of them but afaik, by far the most used, most mature and most complete web framework for Lua). We do not plan to embedd a full fancy web server like Xavante (Kepler's web srv), even with it's incredibly small footprint. Bogdan's concept-proof-yet-to-be-enhanced lhttpd web server offers all I needed here for initial demos and real world small aplications. Now that we have Andre Carregal, Kepler's chief architect here in our list, I thought that it would be great to do a small revision on "elua's way of doing web", to aproach it's concepts, syntax and semantics with the well established Kepler framework. Simple things like the templates file extensions, embedding lua code tags and maybe some srv dispatching functions changing, would make Lua web people feel at home in eLua too (isn't that right Asko ? :). This would be enough for v0.6. Would you like to extend you visions to the small and embedded world too Andr? ? :) Dado -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090218/89f562d5/attachment.html |
|
|
(long mail ahead...)
On Wed, Feb 18, 2009 at 1:44 PM, Dado Sutter <dadosutter at gmail.com> wrote: > Kepler (www.keplerproject.org) is "the Lua way of doing web" :) (it is > actually one of them but afaik, by far the most used, most mature and most > complete web framework for Lua). I wouldn't claim that so fast... let's see how things go first... :o) > We do not plan to embedd a full fancy web server like Xavante (Kepler's > web srv), even with it's incredibly small footprint. Bogdan's > concept-proof-yet-to-be-enhanced lhttpd web server offers all I needed here > for initial demos and real world small aplications. I don't think Xavante would be a good option for eLua. Although Xavante has proved to be an excellent web server for certain applications, eLua needs something more "fire and forget" and Xavante needs some caring if it is supposed to be left running for long periods. The thing is that Xavante uses coroutines to allow multitasking without needing separate threads. While this is great for a developer setup and embedding into applications, it may not be the best solution for devices that need to be on "forever" for example. If one of the requests hang, the other also get stuck. Not a good scenario if you can't reset easily the server... :o) If you have the ability to run threads, then any C level webserver would probably be a better fit. The other solution would be to set a watchdog for Xavante, but I really would not recommend that for eLua. Note that the choice of web server has zero impact in the upper layers due to a decoupling layer called WSAPI. Once you have WSAPI implemented for a certain web server or launching method (CGI, FastCGI etc) you are basically done. Everything else depends mostly on WSAPI to run. Implementing WSAPI for a webserver is usually quite easy. WSAPI is basically a protocol that normalizes how to read data from the webserver (the request) and how to send it back (the response). More details on WSAPI can be found here: http://wsapi.luaforge.net/ Once you have WSAPI in place, you actually can start developing web applications using wsapi.request and wsapi.response. While this is considered "low level", it could be enough for most of eLua needs. If you need something higher level, there are two imediate options. The first would be using CGILua, a PHP like library that handles Lua Pages and Lua Scripts: http://www.keplerproject.org/cgilua/ The other would be using Orbit, a MVC based library that offers some very nice abstractions: http://orbit.luaforge.net/ Note that there is no easy answer as which would be better for every case. One simple solution would be to integrate WSAPI with the embedded web server and then let CGILua and Orbit as options for those who needed it. Once you have one of the page generator solutions in place, you can start using higher level applications for them. One excellent candidate would be Sputnik, that uses only WSAPI. Sputnik is usually seen as just another wiki, but it is way more than that. It is basically an hierarchical node store with versioning. If that is truly useful for eLua applications or not is another question... :o) Sorry if the mail got too long. Andr? |
|
|
Thank you for the explanations Andr?.
They all seem good options for a roadmap planning. What I would like to begin with, for v0.6 if possible, is a _much_ simpler task. I only need to review the net module syntax (maybe to hear some opinions on the semantics but we'll probably not have time to implement it to v0.6) and the template files, for their extensions (lua pages?, lua scripts?). For a WASAPI bind, it seems that we would need a real net.select(). Although we can simulate one with what we have today, this will probably be left for later, as Bogdan will replace our TCP/IP Stack (uIP) for another one, somewhere in the future. Orbit and Sputnik seem very promissing for the embedded world too but not before we have 1MB+ RAM on our kits. This is already available on some with external memory controllers. The main idea of lhttpd.lua was to show that a web server can be completely written in Lua and still perform pretty well. The problems we've had with ours show to have come from uIP, not from lhttpd.lua. It seems to me (although I would like to hear more from you all) that for v0.6 we could: - Change the opening block tag for Lua code in srvr scripts for <% (as used in Kepler) - .lp extension for html files with Lua web scripting code embedded (<% Lua code %> - Review the basic syntax of the net module (I'm sure this will trigger a loooong discussion on many other features :) Dado On Wed, Feb 18, 2009 at 15:14, Andre Carregal <carregal at pobox.com> wrote: > (long mail ahead...) > > On Wed, Feb 18, 2009 at 1:44 PM, Dado Sutter <dadosutter at gmail.com> wrote: > > Kepler (www.keplerproject.org) is "the Lua way of doing web" :) (it > is > > actually one of them but afaik, by far the most used, most mature and > most > > complete web framework for Lua). > > I wouldn't claim that so fast... let's see how things go first... :o) > > > We do not plan to embedd a full fancy web server like Xavante > (Kepler's > > web srv), even with it's incredibly small footprint. Bogdan's > > concept-proof-yet-to-be-enhanced lhttpd web server offers all I needed > here > > for initial demos and real world small aplications. > > I don't think Xavante would be a good option for eLua. Although > Xavante has proved to be an excellent web server for certain > applications, eLua needs something more "fire and forget" and Xavante > needs some caring if it is supposed to be left running for long > periods. > > The thing is that Xavante uses coroutines to allow multitasking > without needing separate threads. While this is great for a developer > setup and embedding into applications, it may not be the best solution > for devices that need to be on "forever" for example. If one of the > requests hang, the other also get stuck. Not a good scenario if you > can't reset easily the server... :o) > > If you have the ability to run threads, then any C level webserver > would probably be a better fit. The other solution would be to set a > watchdog for Xavante, but I really would not recommend that for eLua. > > Note that the choice of web server has zero impact in the upper layers > due to a decoupling layer called WSAPI. Once you have WSAPI > implemented for a certain web server or launching method (CGI, FastCGI > etc) you are basically done. Everything else depends mostly on WSAPI > to run. > > Implementing WSAPI for a webserver is usually quite easy. WSAPI is > basically a protocol that normalizes how to read data from the > webserver (the request) and how to send it back (the response). More > details on WSAPI can be found here: > http://wsapi.luaforge.net/ > > Once you have WSAPI in place, you actually can start developing web > applications using wsapi.request and wsapi.response. While this is > considered "low level", it could be enough for most of eLua needs. > > If you need something higher level, there are two imediate options. > The first would be using CGILua, a PHP like library that handles Lua > Pages and Lua Scripts: > http://www.keplerproject.org/cgilua/ > > The other would be using Orbit, a MVC based library that offers some > very nice abstractions: > http://orbit.luaforge.net/ > > Note that there is no easy answer as which would be better for every > case. One simple solution would be to integrate WSAPI with the > embedded web server and then let CGILua and Orbit as options for those > who needed it. > > Once you have one of the page generator solutions in place, you can > start using higher level applications for them. One excellent > candidate would be Sputnik, that uses only WSAPI. > > Sputnik is usually seen as just another wiki, but it is way more than > that. It is basically an hierarchical node store with versioning. If > that is truly useful for eLua applications or not is another > question... :o) > > Sorry if the mail got too long. > > Andr? > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090218/0af9472a/attachment.html |
|
|
I'm sorry people, but I'm really trying to release 0.6 before the end of
this month, which means next week. Which means we won't be touching nothin on the networking side of 0.6 (as the time it's way too short and that module is very complex), but of course we can talk about the changes that we should implement later. I'll be answering the ADC threads too, soon (I hope). Best, Bogdan On Wed, Feb 18, 2009 at 9:31 PM, Dado Sutter <dadosutter at gmail.com> wrote: > Thank you for the explanations Andr?. > They all seem good options for a roadmap planning. > What I would like to begin with, for v0.6 if possible, is a _much_ simpler > task. I only need to review the net module syntax (maybe to hear some > opinions on the semantics but we'll probably not have time to implement it > to v0.6) and the template files, for their extensions (lua pages?, lua > scripts?). > > For a WASAPI bind, it seems that we would need a real net.select(). > Although we can simulate one with what we have today, this will probably be > left for later, as Bogdan will replace our TCP/IP Stack (uIP) for another > one, somewhere in the future. > > Orbit and Sputnik seem very promissing for the embedded world too but not > before we have 1MB+ RAM on our kits. This is already available on some with > external memory controllers. > > The main idea of lhttpd.lua was to show that a web server can be completely > written in Lua and still perform pretty well. The problems we've had with > ours show to have come from uIP, not from lhttpd.lua. > > It seems to me (although I would like to hear more from you all) that for > v0.6 we could: > > - Change the opening block tag for Lua code in srvr scripts for <% (as used > in Kepler) > - .lp extension for html files with Lua web scripting code embedded (<% Lua > code %> > - Review the basic syntax of the net module (I'm sure this will trigger a > loooong discussion on many other features :) > > Dado > > > > > > On Wed, Feb 18, 2009 at 15:14, Andre Carregal <carregal at pobox.com> wrote: > >> (long mail ahead...) >> >> On Wed, Feb 18, 2009 at 1:44 PM, Dado Sutter <dadosutter at gmail.com> >> wrote: >> > Kepler (www.keplerproject.org) is "the Lua way of doing web" :) (it >> is >> > actually one of them but afaik, by far the most used, most mature and >> most >> > complete web framework for Lua). >> >> I wouldn't claim that so fast... let's see how things go first... :o) >> >> > We do not plan to embedd a full fancy web server like Xavante >> (Kepler's >> > web srv), even with it's incredibly small footprint. Bogdan's >> > concept-proof-yet-to-be-enhanced lhttpd web server offers all I needed >> here >> > for initial demos and real world small aplications. >> >> I don't think Xavante would be a good option for eLua. Although >> Xavante has proved to be an excellent web server for certain >> applications, eLua needs something more "fire and forget" and Xavante >> needs some caring if it is supposed to be left running for long >> periods. >> >> The thing is that Xavante uses coroutines to allow multitasking >> without needing separate threads. While this is great for a developer >> setup and embedding into applications, it may not be the best solution >> for devices that need to be on "forever" for example. If one of the >> requests hang, the other also get stuck. Not a good scenario if you >> can't reset easily the server... :o) >> >> If you have the ability to run threads, then any C level webserver >> would probably be a better fit. The other solution would be to set a >> watchdog for Xavante, but I really would not recommend that for eLua. >> >> Note that the choice of web server has zero impact in the upper layers >> due to a decoupling layer called WSAPI. Once you have WSAPI >> implemented for a certain web server or launching method (CGI, FastCGI >> etc) you are basically done. Everything else depends mostly on WSAPI >> to run. >> >> Implementing WSAPI for a webserver is usually quite easy. WSAPI is >> basically a protocol that normalizes how to read data from the >> webserver (the request) and how to send it back (the response). More >> details on WSAPI can be found here: >> http://wsapi.luaforge.net/ >> >> Once you have WSAPI in place, you actually can start developing web >> applications using wsapi.request and wsapi.response. While this is >> considered "low level", it could be enough for most of eLua needs. >> >> If you need something higher level, there are two imediate options. >> The first would be using CGILua, a PHP like library that handles Lua >> Pages and Lua Scripts: >> http://www.keplerproject.org/cgilua/ >> >> The other would be using Orbit, a MVC based library that offers some >> very nice abstractions: >> http://orbit.luaforge.net/ >> >> Note that there is no easy answer as which would be better for every >> case. One simple solution would be to integrate WSAPI with the >> embedded web server and then let CGILua and Orbit as options for those >> who needed it. >> >> Once you have one of the page generator solutions in place, you can >> start using higher level applications for them. One excellent >> candidate would be Sputnik, that uses only WSAPI. >> >> Sputnik is usually seen as just another wiki, but it is way more than >> that. It is basically an hierarchical node store with versioning. If >> that is truly useful for eLua applications or not is another >> question... :o) >> >> Sorry if the mail got too long. >> >> Andr? >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090218/7c8f4054/attachment-0001.html |
|
|
In reply to this post by Dado Sutter
> Orbit and Sputnik seem very promissing for the embedded world too but not
> before we have 1MB+ RAM on our kits. This is already available on some with > external memory controllers. The current complete Sputnik installation requires 2.2MB, which includes Lua, lfs, lpeg, rings, luasocket + 1.1 MB of Lua code + some things that could be dropped easily. Of the 1.1 MB of Lua code, a good chunk is icons, CSS, etc. It could probably all be fitted in under 1 MB, but not much smaller than that. > - Change the opening block tag for Lua code in srvr scripts for <% (as used > in Kepler) > - .lp extension for html files with Lua web scripting code embedded (<% Lua > code %> You should also consider cosmo for templates. The newer (and better) version requires lpeg, but we have an older (Feb. 2007) version that was pure Lua and only about 100 lines long. - yuri -- http://spu.tnik.org/ |
|
|
In reply to this post by BogdanM
On Wed, Feb 18, 2009 at 4:36 PM, Bogdan Marinescu
<bogdan.marinescu at gmail.com> wrote: > I'm sorry people, but I'm really trying to release 0.6 before the end of > this month, which means next week. Which means we won't be touching nothin > on the networking side of 0.6 (as the time it's way too short and that > module is very complex), but of course we can talk about the changes that we > should implement later. I agree completely, let's work on this for a later release, but I guess we can talk about the issues involved, right? > On Wed, Feb 18, 2009 at 9:31 PM, Dado Sutter <dadosutter at gmail.com> wrote: >> What I would like to begin with, for v0.6 if possible, is a _much_ simpler >> task. I only need to review the net module syntax (maybe to hear some >> opinions on the semantics but we'll probably not have time to implement it >> to v0.6) and the template files, for their extensions (lua pages?, lua >> scripts?). Is there any docs on the current net module API? >> For a WASAPI bind, it seems that we would need a real net.select(). True, but we managed to go quite far with the first version of Xavante running on Symbian. No select() and no threads... :o) >> Although we can simulate one with what we have today, this will probably >> be left for later, as Bogdan will replace our TCP/IP Stack (uIP) for another >> one, somewhere in the future. If you don't mind polling, select() is a luxury. >> Orbit and Sputnik seem very promissing for the embedded world too but not >> before we have 1MB+ RAM on our kits. This is already available on some with >> external memory controllers. I agree that Orbit and Sputnik can wait, but I'm not sure they need that much memory. >> The main idea of lhttpd.lua was to show that a web server can be >> completely written in Lua and still perform pretty well. The problems we've >> had with ours show to have come from uIP, not from lhttpd.lua. No problem, let's focus on the net module then. I just think that once you have a webserver, adding WSAPI is very cost effective. Keep in mind that you can use Cosmo for the templates too, and Cosmo may even be useful for output processing (logs, display etc). >> It seems to me (although I would like to hear more from you all) that for >> v0.6 we could: >> >> - Change the opening block tag for Lua code in srvr scripts for <% (as >> used in Kepler) If you are willing to change the current syntax, I'd suggest trying one of the template processor that are available. We have Lua Pages, Cosmo Pages and Cosmo itself. >> - .lp extension for html files with Lua web scripting code embedded (<% >> Lua code %> That would be Lua Pages. See the lp.lua file in CGILua: http://luaforge.net/plugins/scmcvs/cvsweb.php/cgilua/src/cgilua/?cvsroot=cgilua >> - Review the basic syntax of the net module (I'm sure this will trigger a >> loooong discussion on many other features :) Feel free to hold the discussion until 0.6 is released if you prefer. Andr? |
|
|
In reply to this post by Yuri Takhteyev
On Wed, Feb 18, 2009 at 4:55 PM, Yuri Takhteyev <yuri at sims.berkeley.edu> wrote:
> The current complete Sputnik installation requires 2.2MB, which > includes Lua, lfs, lpeg, rings, luasocket + 1.1 MB of Lua code + some > things that could be dropped easily. Of the 1.1 MB of Lua code, a good > chunk is icons, CSS, etc. It could probably all be fitted in under 1 > MB, but not much smaller than that. True, but note that from that list lfs and luasocket would probably be replaced and rings could be avoided. Lua itself is supposed to be already there... :o) Anyway, this would still be way too much memory and I still think we can start with WSAPI only. WSAPI should take around 30K not compressed and is ROMable. > You should also consider cosmo for templates. The newer (and better) > version requires lpeg, but we have an older (Feb. 2007) version that > was pure Lua and only about 100 lines long. Exactly the one I was thinking about. Andr? |
|
|
In reply to this post by Yuri Takhteyev
Hello,
On Wed, Feb 18, 2009 at 16:55, Yuri Takhteyev <yuri at sims.berkeley.edu>wrote: > > Orbit and Sputnik seem very promissing for the embedded world too but not > > before we have 1MB+ RAM on our kits. This is already available on some > with > > external memory controllers. > > The current complete Sputnik installation requires 2.2MB, which > includes Lua, lfs, lpeg, rings, luasocket + 1.1 MB of Lua code + some > things that could be dropped easily. Of the 1.1 MB of Lua code, a good > chunk is icons, CSS, etc. It could probably all be fitted in under 1 > MB, but not much smaller than that. Thanks for the report Yuri ! I was not familiar with Sputnik's footprint. > - Change the opening block tag for Lua code in srvr scripts for <% (as > used > > in Kepler) > > - .lp extension for html files with Lua web scripting code embedded (<% > Lua > > code %> > > > You should also consider cosmo for templates. The newer (and better) > version requires lpeg, but we have an older (Feb. 2007) version that > was pure Lua and only about 100 lines long. Yes, I would mention Cosmo but I was trying to bring the thread back to what we need for v0.6 :) I've actually tried Cosmo this week and it would be great to refactor webcode in Cosmo's framework, although it would be a bit bigger and depend on on some LuaRocks. I've just modified webbook a bit for our needs (new site and new doc) and the WebBook team accepted the mods, so we will still be in sync with the project. Cosmo seems great for a first embedded template engine for eLua. - yuri Dado > > > -- > http://spu.tnik.org/ > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090218/050b30f0/attachment.html |
|
|
> I've actually tried Cosmo this week and it would be great to refactor
> webcode in Cosmo's framework, although it would be a bit bigger and depend > on on some LuaRocks. You mean it would add 115 lines of Lua? :) The new and more ambitious version of Cosmo is 400 lines of Lua and requires lpeg. The older version, however, is just 115 lines and has no requirements what-so-ever: http://spu.tnik.org/files/cosmo-8.01.21.zip - yuri -- http://spu.tnik.org/ |
|
|
In reply to this post by Andre Carregal-2
This got me thinking, would it be beneficial to dig up my Lumikki (Lua tags embedded in XML) filtering, and use it _dynamically_ (once per each file loaded) instead of statically (as intended). What Lumikki does is it embeds tags such as <@THIS args here=value>whatever</@> within a normal XML, and those tags get processed into Lua calls ( THIS{ args, here=value } kind). Lua script can return anything it wants that gets reformulated as XML. Tags can be recursively within each other, too. Anyways, running these dynamically would basically cover for the server side call issue. Lumikki can be checked out here: svn co svn://slugak.dyndns.org/public/2009/Lumikki -asko Andre Carregal kirjoitti 18.2.2009 kello 20:14: > (long mail ahead...) > > On Wed, Feb 18, 2009 at 1:44 PM, Dado Sutter <dadosutter at gmail.com> > wrote: >> Kepler (www.keplerproject.org) is "the Lua way of doing web" :) >> (it is >> actually one of them but afaik, by far the most used, most mature >> and most >> complete web framework for Lua). > > I wouldn't claim that so fast... let's see how things go first... :o) > >> We do not plan to embedd a full fancy web server like Xavante >> (Kepler's >> web srv), even with it's incredibly small footprint. Bogdan's >> concept-proof-yet-to-be-enhanced lhttpd web server offers all I >> needed here >> for initial demos and real world small aplications. > > I don't think Xavante would be a good option for eLua. Although > Xavante has proved to be an excellent web server for certain > applications, eLua needs something more "fire and forget" and Xavante > needs some caring if it is supposed to be left running for long > periods. > > The thing is that Xavante uses coroutines to allow multitasking > without needing separate threads. While this is great for a developer > setup and embedding into applications, it may not be the best solution > for devices that need to be on "forever" for example. If one of the > requests hang, the other also get stuck. Not a good scenario if you > can't reset easily the server... :o) > > If you have the ability to run threads, then any C level webserver > would probably be a better fit. The other solution would be to set a > watchdog for Xavante, but I really would not recommend that for eLua. > > Note that the choice of web server has zero impact in the upper layers > due to a decoupling layer called WSAPI. Once you have WSAPI > implemented for a certain web server or launching method (CGI, FastCGI > etc) you are basically done. Everything else depends mostly on WSAPI > to run. > > Implementing WSAPI for a webserver is usually quite easy. WSAPI is > basically a protocol that normalizes how to read data from the > webserver (the request) and how to send it back (the response). More > details on WSAPI can be found here: > http://wsapi.luaforge.net/ > > Once you have WSAPI in place, you actually can start developing web > applications using wsapi.request and wsapi.response. While this is > considered "low level", it could be enough for most of eLua needs. > > If you need something higher level, there are two imediate options. > The first would be using CGILua, a PHP like library that handles Lua > Pages and Lua Scripts: > http://www.keplerproject.org/cgilua/ > > The other would be using Orbit, a MVC based library that offers some > very nice abstractions: > http://orbit.luaforge.net/ > > Note that there is no easy answer as which would be better for every > case. One simple solution would be to integrate WSAPI with the > embedded web server and then let CGILua and Orbit as options for those > who needed it. > > Once you have one of the page generator solutions in place, you can > start using higher level applications for them. One excellent > candidate would be Sputnik, that uses only WSAPI. > > Sputnik is usually seen as just another wiki, but it is way more than > that. It is basically an hierarchical node store with versioning. If > that is truly useful for eLua applications or not is another > question... :o) > > Sorry if the mail got too long. > > Andr? > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Yuri Takhteyev
Hello,
On Wed, Feb 18, 2009 at 17:22, Yuri Takhteyev <yuri at sims.berkeley.edu>wrote: > > I've actually tried Cosmo this week and it would be great to refactor > > webcode in Cosmo's framework, although it would be a bit bigger and > depend > > on on some LuaRocks. > > You mean it would add 115 lines of Lua? :) Yes, quite a bit, compared to the 20~30 lines of webbook lua code (besides some JavaScript automatic generation). Unfortunately this also mean "find still more extra time" to work on something totally offtopic. We're using webbook just to simplify the doc and the site handling, not to develop or enhance it as a web framework. For me Cosmo is actually ~400 lines of code, I was not aware of this "old version". The new and more ambitious version of Cosmo is 400 lines of Lua and > requires lpeg. The older version, however, is just 115 lines and has > no requirements what-so-ever: > > http://spu.tnik.org/files/cosmo-8.01.21.zip Thanks ! We'll sure consider it when/if we are focusing on web tools. You could also propose this to the webbook team (which I'm afraid is limited to Scuri today). I really think Cosmo would fit perfectly for webbook, if it does not depend on any extra package/rock. <http://spu.tnik.org/files/cosmo-8.01.21.zip> - yuri Dado > > > -- > http://spu.tnik.org/ > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090218/ffac96f5/attachment-0001.html |
|
|
>> You mean it would add 115 lines of Lua? :)
> > Yes, quite a bit, compared to the 20~30 lines of webbook lua code Webbook is implemented in 20~30 lines of Lua? Plus, are you trying to run webbook on eLua? Why? If not, what difference would 115 lines make, even if the rest of the code is 20 lines? Not to say that I know what purpose cosmo would serve in webbook... - yuri -- http://spu.tnik.org/ |
|
|
Hello,
On Wed, Feb 18, 2009 at 18:57, Yuri Takhteyev <yuri at sims.berkeley.edu>wrote: > >> You mean it would add 115 lines of Lua? :) > > > > Yes, quite a bit, compared to the 20~30 lines of webbook lua code > > Webbook is implemented in 20~30 lines of Lua? Yes Yuri, webbook is a very simple lua script, basically a bunch of gsubs that look for hardcoded tags/constants on 2~3 templates, to generate a pure HTML "site", with a nice hierarchical (JS) menu. > Plus, are you trying to > run webbook on eLua? ?? Not at all :) I'm using it simply to generate our new site (for online browsing) and doc (for offline navigation) in exactly the same way. We'll lose the wiki behavior that Sputnik offers but it is not really necessary for the site today (I plan to use it in the future for an eLua User's Project's site) and things get much simpler, working with a simple HTML offline editor (I'm on KompoZer and open to sugestions) and using our same SVN repo for version control. This also "builds" the distro doc automatically at each commit. Developers can edit the content, not as easy as in a wiki, simply editing (offline) the html files found on the distros/trunk and commiting it back to the repo. Why? If not, what difference would 115 lines > make, even if the rest of the code is 20 lines? Some precious working hours :) Probably much more than what you web-guys would spend :) > Not to say that I know what purpose cosmo would serve in webbook... I'm trying to make this go ahead and Scuri has been receptive. The current version of webbook is pretty old (~2003 I guess) and I have to modify it to our needs, which is really easy and even a web-dumb like me could do that :) Scuri will add my mod to the current version, so we'll keep in sync with the webbook project, which I think is nice. What Scuri does not want is to loose the KISS aspect of webbook. If I understood well, he does not want to rewrite it (I proposed him to find someone here to do that) if the deploy will depend on any installation or external dependency, as most Kepler packages do, even with life made so simple now with LuaRocks. - yuri Dado > > > -- > http://spu.tnik.org/ > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090218/5c134c19/attachment.html |
|
|
In reply to this post by Dado Sutter
Replying again to this one, now with the new mindset in place... :o)
On Wed, Feb 18, 2009 at 4:31 PM, Dado Sutter <dadosutter at gmail.com> wrote: > What I would like to begin with, for v0.6 if possible, is a _much_ simpler > task. I only need to review the net module syntax (maybe to hear some > opinions on the semantics but we'll probably not have time to implement it > to v0.6) and the template files, for their extensions (lua pages?, lua > scripts?). After a better look at the examples and the http server, it's clear that space is a much more high priority than I was assuming. I don't see how we can beat the current web server+request handler+template parser implementation under 4K... :o) > For a WASAPI bind, it seems that we would need a real net.select(). Not really, but forget WSAPI for now. > Although we can simulate one with what we have today, this will probably be > left for later, as Bogdan will replace our TCP/IP Stack (uIP) for another > one, somewhere in the future. I see no problem with the current implementation, and I think only after you have more headroom for Lua code you should spent time on this. > Orbit and Sputnik seem very promissing for the embedded world too but not > before we have 1MB+ RAM on our kits. This is already available on some with > external memory controllers. Then let's leave this as an optional path once you have enough resources. On that case I would suggest checking WSAPI again. But probably only the common.lua part of it, not even the helper modules. > The main idea of lhttpd.lua was to show that a web server can be completely > written in Lua and still perform pretty well. The problems we've had with > ours show to have come from uIP, not from lhttpd.lua. I can imagine that, and I guess the best strategy would be to focus on the TCP/IP stack first. > It seems to me (although I would like to hear more from you all) that for > v0.6 we could: > > - Change the opening block tag for Lua code in srvr scripts for <% (as used > in Kepler) I don't see how this would make much of a difference. The API available for LHP files is already totally different from the one associated with LP files, so there is no point in using the same syntax. It could even lead to confusion. > - .lp extension for html files with Lua web scripting code embedded (<% Lua > code %> Ditto. > - Review the basic syntax of the net module (I'm sure this will trigger a > loooong discussion on many other features :) I still think that you need to have the TCP/IP stack in place before you start changing things in the upper levels. Again, I was using the wrong hat. Sorry for the previous noise on the list. :o) Andr? |
|
|
> I still think that you need to have the TCP/IP stack in place before
> you start changing things in the upper levels. I think you're perfectly right. The current implementation of TCP/IP networking in eLua is somewhat toy-ish, which means "functional, yet too limited to be used in a serious application". This is partly because we use uIP, and partly because of the way we use it, but mostly the first. So we need another stack, but I don't know what to choose. I was going for lwIP, but recently I found many concerns about it: seems to be largely unmaintained (some important several years old bugs were not fixed), there is a lack of functional examples for using lwIP with anything more than "one server port, one client" model (or so I read on other forums) and other stuff like this. Still looking for a better stack that would work well on embedded. Best, Bogdan > > > Again, I was using the wrong hat. Sorry for the previous noise on the list. > :o) > > Andr? > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090222/0217e1d5/attachment.html |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |