On Sun, Nov 20, 2011 at 1:34 PM, Tim Streater <t...@clothears.org.uk> wrote:
> On 20 Nov 2011 at 10:36, Tommy Pham <tommy...@gmail.com> wrote:
>> I think you're approaching this the wrong way.
>> 1) have a clear understanding of PHP - syntax, capabilities, etc.
> That's what I'm doing - gathering information about bits of PHP that I've not 
> used (or not used very much) before to see how my new setup could be 
> structured.

That's a good starting point.

>> 2) have a clear understand of what you're intending to do -
>> application's function/purpose, features, manageability,
>> expandability, portability, etc...
> I have a clear idea about *that*. I want to figure out if it's possible to 
> use web sockets with a small server written in PHP to replace my current 
> structure of ajax + apache + processes (which I suppose it forks). I see 
> these benefits:
> 1) possible benefit - presumably when an ajax request arrives, a new process 
> is started and so PHP has to be loaded and initialised each time. But perhaps 
> this is in some way optimised so the PHP process is left running and apache 
> then just tells it to read/execute a new script.
> 2) Definite benefit - when a browser makes an ajax request to run a script, 
> it gets no information back until the script completes. Then it gets all of 
> it. I have a couple of unsatisfactory workarounds for that in my existing 
> structure. Websockets appears to offer a way for the browser to receive 
> timely information.

You didn't understand my 2nd point completely.  The 2nd point starts
with what function/purpose does the app provide such as is it an
e-commerce, CMS, forum, etc...  What you're talking about is the
process(es) which facilitate(s) the application's functions ie:
"there's more than one way to skin the cat" - so to speak.  Which is
part of manageability, portability, expandability (ie: scaling to
clusters, ease of 3rd party plugins, etc), etc....

>> 3) understand design patterns
> I don't know what this means.

Google "programming design patterns"

>> What your asking is practically impossible in any programming language
>> akin to 'how to un-import packages in Java' or 'how to un-using
>> namespace in C#'.  If you don't want to use it, don't include it ;)
> I do want to use it but would like to be able to replace it with a newer 
> version. If there is no way to do this then that is a data point.

That's why I suggested you read up regarding OOP, including Interface
and Abstracts.  In OOP, you define and guaranteed certain
functionalities with Interfaces - hence the term API (Application
Programming Interface) - but you pass a super/parent class or any of
its sub/child classes, implement those interface(s), to do the work
needed as how you want things done based on certain criteria.  Classic

1) connect to db
2) execute query
3) fetch results
4) process results
5) close connection

given those 5 above steps, there are many ways to proceed about it.
Which way you choose depends on my 2nd point.  In the past, the
standard practice was using client library such as MySQL or MySQLi,
especially prior to PHP5.  Now it's done via PDO or other data
abstraction layer, including ORM depending on a lot of things:
experience, skills, knowledge, project dead line, personal
preference/style, best coding practices, and lazyness in that given
moment - not particularly in those order either.

> And here's another question. Can a child forked by pcntl_fork() use a socket 
> that the parent obtained? Reading the socket stuff in the PHP doc, there are 
> a number of user-supplied notes hinting this might be problematic.
> --
> Cheers  --  Tim


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to