SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,026
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)

    The Problem With AJAX

    I've been reading up on node.js a bit recently. And I've been thinking on the problem of AJAX with regard to PHP and all her frameworks. Before I was introduced to node.js I'd already taken some steps to try to address this problem in my ongoing framework project (which I never seem to get done), but studying node really opened my eyes some to what was going on because, for the most part, node.js is essentially what I'm gunning to build in PHP. But it runs counter to not only the assumptions of all the major frameworks I'm familiar with, but also PHP itself.

    PHP assumes that the browser is going to request a document. This core assumption is why PHP is an embedded language at heart. You take an HTML document, and inject some content into it with a PHP script. Over time the language has evolved, the HTML is shunted into template languages, and MVC frameworks are layered into the language.

    The problem with AJAX is that it allows the browser to ask for a piece of a document - or worse even no document at all. PHP just isn't set up for this and neither is any framework I know of (even my own). While I started moving in this direction it wasn't until a few days ago that I found myself staring in the face and recognizing the core loop code of Gazelle/PNL for what it was, and event dispatch loop.

    And the problem will get worse. Web socket connections are something PHP and *especially* it's frameworks are wholly not ready to deal with. Part of this is overhead - it takes a bit of time to load in, parse and set up the framework on each request, work that is duplicated on every request.

    The Event Paradigm
    PHP is (or at least can be written in the style of ) an object oriented programming language. Most such languages however are event driven. PHP, not so much. There are events, and PHP has the tools to implement the Subject/Observer pattern, but the language is not event driven. Gazelle/PNL was originally scoped to be an event driven MVC, but I'm not beginning to realize that the core mechanism that I have for it - it's event dispatch - would be better served as a PHP extension written in C for best performance - something beyond my keen to do. I can emulate it in PHP, but long term it needs to exist in a manner that it stay resident and sleep between browser requests. The shutdown/start up loop is CPU waste and a scaling constraint for both the language and programs on it.

    I'm a bit lost now. I'm going to continue looking at node.js and see what I can learn. But I'll admit I'm lost and much of my prior structral work isn't going to fly. I'm also debating whether or not it would be more effecient to just use node.js rather than imitate it in PHP.

    Thoughts?

    Actually - this might help.

    Code php:
    /**
     * Start and parse the queue. 
     */
    public function parse( $url = '/' ) {
    	$this->parseURL($url);
     
    	// Let the heartbeat commence.
    	do {
    		// Get an event.
    		$event = array_shift($this->queue);
     
    		try {
    			// If the event is a page, assign it and clear the queue and responses.
    			if ( $event instanceof Page ) {
    				$this->startPage($event);
    			}
     
    			$result = $event( $this->page );
     
    		} catch ( Exception $e ) { // Uh oh - error page time.
    			/*
    			 *  If the page is an error page, we need to elevate to fatal
    			 * exception or run the risk of getting caught in a loop.
    			 */
    			if ($this->page instanceof ErrorPage ) {
    				throw new FatalException($e->getMessage);
    			} else {
     
    				/*
    				 * Resolve gracefully. Note that these errors can be cause
    				 * by user interaction - 404 not found pages pass through
    				 * this mechanism.
    				 */  
    				$ep = $this->dataDispatcher->getSetting('core', 'errorPage');
     
    				$this->startPage (
    					new $ep( $e, $event, $this )
    				);
    			}
    		}
     
    		// An event may return multiple events, especially pages.
    		if (is_array($result)) {
    			foreach ( $result as $r ) {
    				$this->route($r);
    			}
    		} else { // Handle just the one result.
    			$this->route($result);
    		}
    	} while( count($this->queue) > 0);
     
    	/*
    	 * Now as our last step we give the page to the responseDispatcher
    	 * for the handling of the reply.
    	 */
    	$this->responseDispatcher->respond();
     
    }

    My whole framework is built around this function, which loops over an event stack created by parsing the URL information provided by the browser. When the events all resolve, the response gets issued. But couldn't this be btter placed lower down?

  2. #2
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Hi Michael,

    Are you thinking to use node.js as the event dispatch side of your framework? Or are you saying that you would scrap Gazelle in PHP and redo all of it in node.js?

    Steve
    ictus==""

  3. #3
    SitePoint Zealot
    Join Date
    Jan 2011
    Location
    Portland
    Posts
    148
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    if i understand you correctly are you trying to make ajax for php? or just basic event driven programming?
    coming soon sitejuju.com my new development portfolio

  4. #4
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Nevermind I know what you are talking about... looked into Node.js today... very cool.

    Given that I don't know much yet about Node.js then I will likely contribute very little value.

    Steve
    ictus==""

  5. #5
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    No offense, but top to bottom that is so full of misunderstandings, misinformation, and outright overthinking problems that to be brutally frank, aren't even problems in the first place.

    There's just some serious whiskey tango foxtrot here.

    Quote Originally Posted by Michael Morris View Post
    PHP assumes that the browser is going to request a document.
    Uhm... tell that to people who use PHP on the command line... tell that to running it as a instance or as a cron job...

    Quote Originally Posted by Michael Morris View Post
    This core assumption is why PHP is an embedded language at heart.
    Not sure what the devil that even MEANS. Usually "embedded language" means written for things like thin clients -- so unless once again they've changed the meaning, that's gibberish.

    Quote Originally Posted by Michael Morris View Post
    You take an HTML document, and inject some content into it with a PHP script. Over time the language has evolved, the HTML is shunted into template languages, and MVC frameworks are layered into the language.
    Uhm... No? Templating has been possible since day one, and frameworks are written IN the language, they are not "layered into it". That would imply they are PART of PHP, and they aren't.

    Quote Originally Posted by Michael Morris View Post
    The problem with AJAX is that it allows the browser to ask for a piece of a document - or worse even no document at all.
    How is that a 'problem' -- php just processes requests; it doesn't have to return bupkis... shouldn't even happen unless you're doing something stupid like the "let's open and close php on every line" nonsense. (there's a reason I'd like to see <?php and ?> removed from PHP completely)

    Quote Originally Posted by Michael Morris View Post
    PHP just isn't set up for this
    Since when?

    Quote Originally Posted by Michael Morris View Post
    and neither is any framework I know of (even my own).
    I could once again go off on some massive tirade about what total idiotic garbage frameworks are in an INTERPRETED language, but of course just like the goofy programmer extension cartridges for the VIC-20, BBDB for M$ ROM BASIC, or the dozen other complete nonsense people ended up using in the 80's, history just keeps repeating itself.

    Quote Originally Posted by Michael Morris View Post
    And the problem will get worse. Web socket connections are something PHP and *especially* it's frameworks are wholly not ready to deal with.
    Really, so what exactly is wrong with doing this from the command line:

    php socketserver.php localhost 8080

    With maybe a cron job to call that and have it check that it is indeed running every say... five to ten minutes? Handles it like a champ... WHAT ARE YOU EVEN GOING ON ABOUT?!?

    Quote Originally Posted by Michael Morris View Post
    PHP is (or at least can be written in the style of ) an object oriented programming language.
    If by that you mean a poorly implemented and crippled one, then sure. There's a reason objects aren't as good a solution to many problems as they are in REAL languages...

    Quote Originally Posted by Michael Morris View Post
    Most such languages however are event driven.
    Since when? While you can implement event driven IN OOP languages, you can do so in procedurals as well and it's not something "built into the language". (though the line does blur with the built in system libraries and/or OS/UI/WM libraries that come with many languages). Smalltalk isn't 'event driven'... Object Pascal isn't... C++ certainly isn't...

    Quote Originally Posted by Michael Morris View Post
    PHP, not so much. There are events, and PHP has the tools to implement the Subject/Observer pattern, but the language is not event driven.
    Neither are any other languages... You write a windows API "event driven" C++ or Pascal program, you're still passing the OS the event handler and manually passing the response; the language doesn't do "events" all on it's own. This is no different than opening a socket with socket_create, then looping to monitor for events... an OS side hook to directly call your PHP every time there was a port event would be 'nice' -- but if you took a peek under your average desktop 'event driven' application, well... (excuse the windows API stuff)

    Code:
    while (GetMessage(*AMessage,0,0,0)) {
    	TranslateMessage(AMessage);
    	DispatchMessage(AMessage);
    }
    Which then trips WindowProc with the AMessage.

    Your example code, which I'm not even certain where it would be called or what it's supposed to even do, looks like you're REALLY overthinking something simple.

    Though that could just be an over-reliance on frameworks instead of just writing it properly from the start messing you up... that and a number of false assumptions about PHP, AJAX, Websockets, and the various technologies/languages in general... It does sound like you're coming to a conclusion I came to about a year ago though -- MVC has no business being applied to PHP.

  6. #6
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Deathshadow60,

    So if you came to this conclusion
    It does sound like you're coming to a conclusion I came to about a year ago though -- MVC has no business being applied to PHP.
    then what do you do other than MVC that you think is better?
    ictus==""

  7. #7
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ServerStorm View Post
    So if you came to this conclusion then what do you do other than MVC that you think is better?
    The natural order in which database applications have worked since the days of DBASEIII/Clipper.

    Receive the user request
    Process the request
    Output the result

    Which sounds like the same thing (originally I thought that's what people MEANT by MVC in PHP) -- but really MVC is best left as a desktop or 'real time' paradigm. It's often funny people think of PHP as not being event driven, when it actually is; it's just that there's only ONE type of event a php app handles in normal operation (as opposed to leaving it running indefinitely from the command line) -- user requests. That's your event... NORMAL PHP applications do not sit there running all the time, but are called when a user request (the event) is sent.

    It's why MVC doesn't make any sense and seems to result in bloated messes needing frameworks -- the model "isn't there" and to be frank building one is a waste of time. To borrow from wikepedia, take a look at the MVC flowchart:

    http://en.wikipedia.org/wiki/File:Mo...erDiagram2.svg

    It's designed for situations where the code runs as a endless loop polling for events; that's not what PHP does in normal operation! Even if you considered the browser and server to be the 'model' part, it breaks down because the moment you output a result you're done. PHP is a top down interpreted language; there is no 'constant loop' or 'internal events' to build a model around; even attempting to do so is silly.

    PHP apps should be built as a straight line, not a closed loop -- Take the user request (URL, getData, PostData, cookies), turn it into your SQL queries or other data building methods, run those queries/data gathering, output the result. It's not rocket science -- people just seem to try to turn it into rocket science by banging that square peg into the round hole with a double deuce lump.

    Basically, just use PHP in the order it's designed to be used in rather than trying to shoehorn some vague bit of theoretical programming into it like squeezing a 500 pound woman's size 12 hoof into a size 6 shoe.

    In my own WIP CMS (which is now seeing it's 8th revision) I do practice some separation -- I have the central index.php which does any further splitting of user requests into something the data processor can handle, I then build ALL the data into an array before sending it for output; in fact I don't allow ANY of the code to output ANYTHING until ALL of the data has been build. This uses a bit more memory than I'd like, but actually seems to build the result faster (by keeping all disk access together and all network output together). It also makes theming easier as all the theme has to do is glue HTML around the result in one flat pass, while the data gatherer only has to worry about putting the data in a big array as opposed to worrying about calling the theme at all. Also means you can re-arrange the output theme-side to any order you like without changing the order of the data gatherer.

    Request pre-processor -> data gatherer -> theme

    Straight line - how simple is that?

    Of course, it's probably why most alleged PHP 'MVC' frameworks toss on a bunch of pre-written library functions like e-mail handling onto them; much like jquery with it's alleged "cross browser issue" revolution and then finding out 80% of the codebase is for goofy animated transitions -- they have to slather frosting on top to hide that the cake underneath is bland, dry and flavorless.

  8. #8
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by deathshadow60
    In my own WIP CMS (which is now seeing it's 8th revision) I do practice some separation -- I have the central index.php which does any further splitting of user requests into something the data processor can handle, I then build ALL the data into an array before sending it for output; in fact I don't allow ANY of the code to output ANYTHING until ALL of the data has been build. This uses a bit more memory than I'd like, but actually seems to build the result faster (by keeping all disk access together and all network output together). It also makes theming easier as all the theme has to do is glue HTML around the result in one flat pass, while the data gatherer only has to worry about putting the data in a big array as opposed to worrying about calling the theme at all. Also means you can re-arrange the output theme-side to any order you like without changing the order of the data gatherer.
    That sounds exactly how the more popular MVC frameworks function. Your just using scewing terminology and perhaps less abstraction. Still though that is how they work. They don't work in a circular paradigm but linear one just like your explaining. That is why I often say PHP, Ruby, ect frameworks aren't actually true MVC but a modified version of it.
    The only code I hate more than my own is everyone else's.

  9. #9
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    That sounds exactly how the more popular MVC frameworks function.
    I originally thought so too, but like a year ago there was another thread about MVC where I said I was doing it this way and everyone and their brother pig-piled saying it wasn't what MVC is... Looking deeper at the absolute disaster of code these "MVC Frameworks" actually were I started to agree; and eventually found MVC in PHP the way said libraries work was absolute 100% snake-oil thanks to being needlessly convoluted.

    Besides, what I describe is so malfing simple what in blue blazes does it need a 'framework' for?!? Much less these monstrous train wrecks of code people get DUPED into using out of ignorance -- But then, I say that about 99% of the stuff people use frameworks for in INTERPRETED languages... where the mere concept of a framework is typically nothing more than pointless bloat and something ELSE to learn on top of the host language -- at which point it often prevents people from actually LEARNING the host language and being qualified to say if said framework is crap or not.

    See, well... do I need to say what 'framework' I'm thinking of? Here's a tip, it's NOT PHP based.

    Though, I could also have soured on MVC just because it reeks of college-speak... the type of thing where "You had to go to college to say something this stupid"... Complex terms and esoteric theory when all we really need to say is

    Ask it, Get it, show it!

    Which in six words explains my approach better than the average five page white-paper explains MVC.

  10. #10
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    The most significant problem I have using AJAX is balancing gracefully degradation without repetition. Generally applying only to AJAX requests with send back data in the raw form (XML, JSON) but need to be represented on screen. It can tricky to do that without either repeating logic to rebuild the HTML in JavaScript to present the data or having a JS template in place that repeats the same logic as server side code. I have really yet to tackle that issue. So I tend to always send back HTML and merely append it to the DOM using innerHTML or html() in jQuery.

    The other portion of this is form processing. Generally when you process a form using AJAX the new form state is necessary. I normally achieve that in one of two ways. The first is to send back the complete form as HTML in its new state. The other is to only send back errors, etc and update only the necessary pieces of the DOM to rebuild the display after submission including en field errors or global form messages. Lately with the technologies I have to work with I have been taking the former approach – sending back the HTML for the new form or its state and adding it directly to the DOM just like with aggregated data in list or tables.

    The other one which partially applies to forms is reloading form elements. Some form elements such as; linked list (dependent selects) and auto completes require JavaScript. Providing a means of gracefully degrading something with such a large data set where it requires one of those can be very painful. In fact I tend to not provide graceful degradation for those only using them in admin areas where JavaScript is a known requirement.

    Where managing AJAX always tends to come tricky is providing graceful degradation for it… at least for me anyway. The simplest approach without a doubt always seems to be sending back a partial page rendering with only the data that needs to be replaced than simply using innerHTML or jQuery.html().

    Having said all this I have only briefly looked over node and wouldn't really be comfortable comparing it to anything at this point. The one thing I would be concerned with is deployment. Using on a personal project seems like it would require a very specific hardware set-up that would be hard to come by in a shared environment. Using it for professional projects would add yet another framework for people to understand on top of all the others that we use not to mention our server guys to learn something new as well in regards to managing a site using node and installing it on our hard ware. I don't think the advantages outweigh all the work involved in doing so.
    The only code I hate more than my own is everyone else's.

  11. #11
    From space with love silver trophy
    SpacePhoenix's Avatar
    Join Date
    May 2007
    Location
    Poole, UK
    Posts
    5,016
    Mentioned
    103 Post(s)
    Tagged
    0 Thread(s)
    Off topic posts removed. If anyone feels that a post made by anyone is offensive/a personal attack/trolling/etc please don't respond to it. Report the post concerned using the report post button (the orange flag icon).
    Community Team Advisor
    Forum Guidelines: Posting FAQ Signatures FAQ Self Promotion FAQ
    Help the Mods: What's Fluff? Report Fluff/Spam to a Moderator

  12. #12
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Thanks for describing what you do Deathshadow60.

    There has always been a lot of confusion regarding what MVC is or isn't, probably why you don't see it clearly implemented in the frameworks you've studied. Your approach seems to separate concerns so in many ways you are creating the same separation that MVC touts, only for you, this works better. It is a straight forward way of doing things and I like how you can easily theme based on how you collect the output.

    Steve
    ictus==""

  13. #13
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,026
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)
    On some level websites are already divided by MVC lines.

    Model - HTML DOM
    View - CSS rules
    Control - Javascript

    That's oversimplifying things a little, but isn't that what it boils down to? Separation of the code for data, behavior, and appearance.

    Why do we separate these? To attack the complex graph problem inherent in large system design. Deathshadow's philosophy works - up to a point. It falls apart in a team environment.

    Separation of the code into discrete independently testable units becomes a requirement after code reaches a certain size. Design paradigms provide guidelines - not rules - on how this separation might - not must - occur.

    The problem and the challenge of Ajax to continue from my first post, is that it invites a tightening of integration that PHP - as a web service language. That PHP can be ran from the command line or that socketserver scripts can be written with it is beside the point Deathe - This is not the context of the language most programmers are familiar with. Nor is it the context the language was conceived. The original PHP and PHP2/FF where template engines for C++ scripts and little more. Only with PHP 3 did the functionality you describe begin to be layered onto the language. And while that functionality is there, not many people use it because there are better tools for the job - Perl and Python are far more common command line scripting languages, Java tends to dominate socket services in the present.

    And then there's node.js. Node bypasses the webserver and that introduces a world of complexity on it's own.

    Most of the PHP scripts out there are web scripts. A webserver calls them up and they do what they do and go to sleep. This is a direct mirror to how web pages worked 10 years ago - The browser took information from the server a page at a time. Partial pages and behavior weren't factored into this design.

    Is MVC appropriate to the PHP script? It is true that PHP itself doesn't store the data state - that is the duty of the database program, usually MySQL. It is likewise true that PHP doesn't manage the view state - that is the duty of the browser on the client machine. If anything, in the strictest sense, PHP is the controller in this architecture - the go between. And in this light it should not be surprising that MVC implementations in PHP frequently forget that the view can talk to the model in the MVC paradigm. Until Ajax showed up such communication wasn't practical. Now it is.

    Now we have pages that have pieces that are static and pieces that are dynamic. It would be nice to figure out a way to powerfully cache those static pieces and concentrate on the dynamic ones. It would also be great to, when building a template for a page section, not worry with whether it will be parsed within the delivery of a whole page, or be delivered by itself for insertion by javascript. Great would being able to do both. That's the problem I'm trying to solve.

    What I have in abstract is this - organization of website elements by pages and zones. Definition time:

    A page is a web document resource with a distinct URI. The browser can cache or bookmark it.
    A zone is a piece of a page. Multiple pages may share a zone. Advertising software works by zones and that's where I got the idea - why not divvy the whole page this way.

    The loop I gave above gets a browser request - but that request might be for a page (a page event) but it may only be a zone event, where an AJAX interaction is underway. Consider a homepage with 4 zones: news, login, navigation, advertisement. When the page is first visited we deliver these 4 zones in their state for the guest user. The next event is the login zone processing a login from post. If successful we need to update the navigation and login zones, possible order the news zone to toggle on the edit controls for a user with those permissions.

    If AJAX is disabled, the page must reload and ideally, this shouldn't need special scripting. PHP recomposes the entire page, and not just the relevant elements.

    Still, Ajax events will be distinct from full page request events in how they are handled. The fulfillment of any one request may still be linear, but the possible requests branch out often and somewhat unpredictably.

  14. #14
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by oddz View Post
    The most significant problem I have using AJAX is balancing gracefully degradation without repetition. Generally applying only to AJAX requests with send back data in the raw form (XML, JSON) but need to be represented on screen. It can tricky to do that without either repeating logic to rebuild the HTML in JavaScript to present the data or having a JS template in place that repeats the same logic as server side code. I have really yet to tackle that issue. So I tend to always send back HTML and merely append it to the DOM using innerHTML or html() in jQuery.
    For most of the AJAX that I do, this is the same issue and way I mostly deal with it. However, recently I did an App that detected if javascript was available and if so it did the php/html -> asynchronous post request -> get data back -> present. If javascript was off then the App knew to switch to the more traditional php/html -> $_POST (page refresh) -> get data back and process data -> present. This is more work.

    Quote Originally Posted by oddz View Post
    Having said all this I have only briefly looked over node and wouldn't really be comfortable comparing it to anything at this point. The one thing I would be concerned with is deployment. Using on a personal project seems like it would require a very specific hardware set-up that would be hard to come by in a shared environment. Using it for professional projects would add yet another framework for people to understand on top of all the others that we use not to mention our server guys to learn something new as well in regards to managing a site using node and installing it on our hard ware. I don't think the advantages outweigh all the work involved in doing so.
    Looking more deeply into Node.js, it needs to be compiled onto your Linux or FreeBSD server (MacOS too buggy yet). The author of Node.js does not believe it is ready for production yet and said that its' primary use is for small 'fast' services that you need beside your more traditional php/apache or rails/ngix. He said that many of the C bindings are not yet ready, so Database usage with the exception of MongoDb or Postgre are not well supported yet. Also http niceties that PHP have wrapped up are also not yet written in C.

    If you feel comforatable in C then you could wrap your own bindings, but until (or if) Node.js matures a little and more bindings are available most of the work is Low level. Michael I know that you mentioned that you want to stay away for this.

    Regards,
    Steve
    ictus==""

  15. #15
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,026
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)
    Yes I did. That doesn't mean I can't take notes.

  16. #16
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    Yes I did. That doesn't mean I can't take notes.
    True

    Given that your framework has been in the making a long time, then Node.js may be ready for you next time your ready to proceed with development. I know that Node.js has gain an active interest and Yahoo is doing a lot of work on the bindings right now. So maybe sooner than later?

    After researching Node.js, it seems to me that it is less about an event driven structure and more about non-blocking versus blocking functions. At present PHP and MySQL both operate using blocking functions, so you will not be able to achieve a non-event blocking framework in PHP.

    I for one am keeping a keen interest in Node.js as the methodology makes so much sense to me. As bindings and abstraction of the low level Node.js libraries are made, the author of these bindings and abstractions could choose to ignore the non-blocking philosophy so by the time consumption from higher level programmers (PHP, javascript...) is easy enough then the real benefit of why Nod.js was written, may be lost. If history is repeating itself like Deathshadow60 says, then that is an all too real possibility. So a risk is, you could wait only to find out that you are largely dealing with similar issues to what you face with PHP? Hopefully the binding authors do focus on non-blocking designs.

    Regards,
    Steve
    ictus==""


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •