Thinking about Chromebooks because my son, a 4'th grade teacher will be using them in his school.
Still just a browser in a box? So we'll be waiting for livecode export to html5? Bill William Prothero http://es.earthednet.org > On Apr 1, 2015, at 8:55 AM, Richard Gaskin <ambassa...@fourthworld.com> wrote: > > GMTA: the folder where I keep my experimental server stacks is named > "LiveNode". :) > > Good stuff here, a very useful and practical pursuit, IMO, in a world where > one of the largest MMOs is also written in a high-level scripting language > (EVE Online, in Python) so we know it's more than possible to consider a > full-stack server solution entirely written in LiveCode: > > David Bovill wrote: > > > The question is can you create in Livecode an aynchronous event-drive > > architecture? Livecode is built after all around an event loop, and > > through commands like dispatch, send in time, and wait with messages, > > it is possible to create asynchronous call back mechanisms - so why > > can we not create a node-like server in Livecode? > > > > Perhaps the answer lies in the nature of the asynchronous commands > > that are available? Still I don't see why this in an issue. From > > my experience of coding an HTTP server in Livecode - I cannot > > understand why it should not be possible to accept a socket > > connection, dispatch a command, and immediately return a result on > > the connected socket. The event loop should take over and allow > > new connections / data on the socket, and when the dispatched > > command completes it will return a result that can then be send > > back down the open socket. > > I've been pondering similar questions myself: > <http://lists.runrev.com/pipermail/use-livecode/2015-February/211536.html> > <http://lists.runrev.com/pipermail/use-livecode/2015-March/212281.html> > > Pierre's been exploring this even longer: > <http://lists.runrev.com/pipermail/metacard/2002-September/002462.html> > > With socket I/O apparently handled asynchronously when the "with <message>" > option is used, this is a very tempting pursuit. > > The challenge arises from the recipient of the message: it will be running in > the same thread as the socket broker, causing a backlog of message queueing; > requests are received well enough, but responding requires then to be > processes one at a time. > > Down the road we may have some form of threading, though that's not without > programming complication and threads are somewhat expensive in terms of > system resources (though there are options like "green threads" at least one > Python build uses). > > Working with what we have, Mark Talluto, Todd Geist, and I (and probably > others) have been independently exploring concurrency options using > multiprocessing in lieu of multithreading, using a single connection broker > feeding processing to any number of worker instances. > > The challenge there is that the LC VM is not currently forkable, so we can't > pass a socket connection from the broker to a child worker process. > > Instead, we have to look at more primitive means, which tend toward two camps > (though I'm sure many others are possible): > > a) Consistent Socket Broker > The socket broker handles all network I/O with all clients, and > feeds instructions for tasks to workers via sockets, stdIn, or > even files (/sys/shm is pretty fast even though it uses simple > file routines). > > The upside here is that any heavy processing is distributed among > multiple workers, but the downside is that all network I/O still > goes through one broker process. > > > b) Redirects to Multiple Workers > Here the main socket broker listening on the standard port only > does one thing: it looks at a list of available workers (whether > through simple round-robin, or something smarter like load > reporting), each of which is listening on a non-standard port, > and sends the client a 302 redirect to the server with that > non-standard port so each worker is handling the socket comms > directly and only a subset of them. If each worker also has > its own collection of sub-workers as in option a) above, this > could greatly multiple the number of clients served concurrently. > > The upside is that all aspects of load are distributed among > multiple processes, even socket I/O, but the downside is the > somewhat modest but annoying requirement that each request > be submitted twice, once to the main broker and again to the > redirected instance assigned to handle it. > > > Purpose-built application servers can indeed be made with the LiveCode we > have today and can handle reasonable amounts of traffic, more than one might > think for a single-threaded VM. > > But all systems have scaling limits, and the limits with LC would be > encountered sooner than with some other systems built from the ground up as > high-load servers. > > IMO such explorations can be valuable for specific kinds of server apps, but > as tempting as it is I wouldn't want to build a general purpose Web server > with LiveCode. In addition to the scope of the HTTP 1.1 spec itself, Web > stuff consists of many small transactions, in which a single page may require > a dozen or more requests for static media like CSS, JS, images, etc., and > Apache and NgineX are really good solutions that handle those needs well. > > I think the sweet spot for an entirely LiveCode application server would be > those apps where backend processing load exceeds network I/O. > > As interesting as these things are, I have to admit I currently have no > practical need for such a creature, so my brief experiments have been few and > limited to an occasional Sunday with a free hour on my hands. :) > > If you have such a need it would be interesting to see how these things flesh > out under real-work load. > > > > Assuming there is an issue with the above, the next question is > > that given that Node already can be extended with C / C++ > > extensions api - so why not treat Livecode as simply a Node > > extension and let Node do the async event driven I/O that it is > > so good at? > > I have no direct experience with either Node.js or NgineX, so I'm out of my > depth here - but that won't stop me from conjecturing <g>: > > My understanding is that LiveCode, being single-threaded today, is limited to > CGI, while Node.js and NgineX expect FastCGI (forkable) support. > > If you can get LiveCode to run well under Node.js I'd be very interested to > see what you come up with. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
