So, as far as I see it, we will not be needing the Filter, or Access Control mechanisms for FCGI (at least to begin with), what do you guys say?
On Wed, Oct 26, 2011 at 5:02 PM, Dhaivat Pandya <dhaivatpan...@gmail.com>wrote: > I also agree. Javascript just never occurred to me... > > > On Wed, Oct 26, 2011 at 1:13 AM, Mark Constable <ma...@renta.net> wrote: > >> On 2011-10-25 11:32 PM, Gábor Lehel wrote: >> > > Lastly, ties to a scripting language would be excellent, and it >> > > would be great if we could start with Lua since it is dead simple >> > > to tie in with C/C++ code, and then add Python capability as we >> > > get going farther into the project. >> > >> > I am not participating in this project and don't know anything about >> > anything, but wouldn't JavaScript be the logical choice, given that it >> > already ships with and is integrated to some degree with Qt? >> >> Totally agree, V8 in particular. The main reason for focussing on JS is >> that the language itself is entirely async which fits in nicely with >> Qt's signal/slot async event driven potential. Personally, I have no >> interest in using anything but Javascript, with PHP as a sync based >> fallback because of the huge amount of "legacy" web apps available. >> >> https://github.com/nikhilm/confkdein11/tree/master/qtjs >> >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
