in reply to Current Thoughts on Server/Client Best Development Strategies

A timely question. :-) I have been looking at Web 2.0, node.js, jquery, and all the other javascript libraries coming out now.

It seems to me, that the general strategy is to find a way to do non-blocking I/O, so that one of your html div's dos'nt stall the whole page.

Of course, after playing around with a few Perl GUI libs, like Tk and Gtk2, you see the value of not having direct socket connection loops as your main loop. Instead, you run event-loop systems on both ends, both the socket and the server. The event-loops make and service the socket connections, so the sockets can be read or written to, in a non-blocking manner.

So, the whole idea of Web 2.0 is to break your monitor/screen into little divs( divisions), and each little div can run it's own javascript routine, automatically opening sockets and transferring information. So with event-loop based non-blocking I/O, many sockets can be simultaneously opened from your browser window, and be updating independently, without requiring an entire page refresh, you only need to refresh the div which originated the socket request.

The much heralded node.js is nothing more an eventloop system, written in javascript, which can handle JSON ( javascript object notation) packages of data. Furthermore, javascript itself is the eventloop running your browser. If you turn off javascript, you only prevent external scripts from being run, but the basic browser eventloop continues to run.

So..... if I was designing a general purpose strategy, it would be to be eventloop based, on both the server and client, AND the client should be able to be integrated into a web browser, which should be easy enough with javascript. It needs to handle things like I/O Promises, which is the eventloop's way of saying the "information is being readied for delivery".

Those are my current thoughts. :-)

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh
  • Comment on Re: Current Thoughts on Server/Client Best Development Strategies

Replies are listed 'Best First'.
Re^2: Current Thoughts on Server/Client Best Development Strategies
by three18ti (Monk) on Feb 01, 2014 at 14:24 UTC

    Why do you think the client should be integrated into a browser?

    I don't think I disagree with you, in today's day and age, EVERYTHING runs in a browser. But maybe there's a good reason to have a client that isn't browser integrated.

[reply]
      I agree, I don't understand why there are not more custom clients out there. It seems everyone likes the standardization of the browser, and to be honest, with the HTML5 canvas element, it seems everything can be done... any custom widget can be made, running right in a browser. Plus, cell phones and smart phones have a built-in browser.

      If I had a business that needed sockets, I would avoid the browser myself, except for putting a page out to the public. Internal parties, would avoid the filtering thru the various web servers, and open direct socket connections .... like a RealTime Chat with video between endpoints. See Tk encrypted echoing-chat client and server and ztk-enchat encrypted server client for some crude prototypes.

      As a matter of fact, the latest cool new APP out there seems to be something called Between, which allows realtime chat, with videos, between 2 people, it's always on connecting you to your honeybunch. :-)

      What we really could use, is a version of Perl, written in javascript, which can be run in browsers as javascript. Python is already working on it, as there is an option for it in the firefox configure options.

      I'm not really a human, but I play one on earth.
      Old Perl Programmer Haiku ................... flash japh
[reply]

        Wait. Wait. Wait...

        > What we really could use, is a version of Perl, written in javascript, which can be run in browsers as javascript.

        You mean like a javascript compiler that JIT perl code? How would we do it? would it compile the perl to JS? or?

        Everytime I talk to you you leave me with homework ;) I've got a bit of research to do. (those links are pretty interesting).

        Thanks!

[reply]

In Section Seekers of Perl Wisdom