Hi Richard and Andre - thanks for your replies. I was the one who mentioned millions of users at the same time, not out of drunkenness but because I wanted to understand the upper limits of these systems.
I also found a thread discussing this idea from a few years ago that Richard was part of. It was very informative. I think an all-LC very fast server would be a great thing, but it sounds like just using node would be more realistic. I might fiddle a bit with this idea, just to satisfy my curiosity. Sent from my iPhone > On Dec 4, 2017, at 1:40 PM, Richard Gaskin via use-livecode > <use-livecode@lists.runrev.com> wrote: > > Andre Garzia wrote: > > > On Mon, Dec 4, 2017 at 3:13 PM, Richard Gaskin via use-livecode wrote: > ... > >> I don't even think we'd need tsNet for that. Sockets should suffice > >> for communicating between backend services, and using the "with > >> messages" option makes them async; indeed that single-threaded > >> message-driven approach is a big part of what makes Node.js so > >> performant, offloading as much as practical from the process thread > >> to the OS. > ... > > IMHO opinions it is not fair to compar NodeJS and LC Server on merits > > of performance because they are really different beasts... > ... > > All this changes both inside the language itself and on top of it > > in form of syntatic sugar serves one purpose only, give the developer > > good ergonomics while keeping the code asynchronous/non-blocking. > > > > LiveCode is not an asynchronous language. It has some APIs that work > > asynchronously when we want them to, but it is not a non-blocking > > engine. > > The stylistic differences, and their implications in implementation, is > indeed important. Thanks for that outline. > > Google's massive investment in JS will be hard to match for anyone seeking to > deliver equivalent systems. > > Which leaves us asking: When you want something like Nide.js, why not just > use Node.js? > > > > > All our "PUT URLs" calls are blocking... > > Take a second look at the original libURL code. IIRC, in the course of > exploring some other issues in which what I wanted was truly sync behavior > but finding it difficult to actually achieve it, it seems libURL is using the > "with messages" option for socket calls, and where sync is needed that's > emulated within an async socket method. > > Not sure why, and I've been tempted to write my own HTTP client code just to > make sure I get truly sync behavior when I need it (hoping I'll find a way to > get that with tsNet once I get back to that problem). > > But if it's of interest, take a gander at libURL and let me know if I've > overlooked something. If nothing else I'll finally have the true sync > behavior I'm looking for. But we may also find that socket comms in LC, when > using the "with messages" option, use callbacks in a way that efficiently > leverages OS integration. > > Of course this alone doesn't put LC on par with Node.js, for all the reasons > you noted. But it does potentially offer opportunities for reasonably > efficient socket comms, which may be esp. useful on backends where all we > need are sockets, not necessarily encumbered with also supporting HTTP on top. > > > > Your original email about scaling anything to millions of users > > doesn't outline some needs of working at that scale. > > If I ever wrote that I was drunk. But I don't recall writing that; it's not > consistent with my thinking. I've done enough testing on the C10k problem to > be well aware of the challenges of attempting C10m. > > When big systems are needed, big ecosystems help. As a > right-tool-for-the-right-job kinda guy, I generally advocate industry > standards for such things. > > -- > 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
