FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » anyone else writing Linux (or cross-system) applications in PHP?
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: anyone else writing Linux (or cross-system) applications in PHP? [message #180310 is a reply to message #180299] Mon, 04 February 2013 16:06 Go to previous messageGo to previous message
Jonathan N. Little is currently offline  Jonathan N. Little
Messages: 12
Registered: February 2011
Karma:
Junior Member
crankypuss wrote:
> On 02/03/2013 12:00 PM, Jonathan N. Little wrote:
>> crankypuss wrote:
>>> On 02/03/2013 08:17 AM, Jonathan N. Little wrote:
>>
>> <snip>
>>
>>>> I don't think so. Since its original name was "Personal Home Page
>>>> Tools"
>>>> for scripts to facilitate created personal webpages on a server speaks
>>>> to its origins. How an application interacts in with the user from a
>>>> webserver is very different from that of a desktop application.
>>>
>>> It's okay if we disagree on this, you're allowed to be incorrect. <G>
>>
>> Not sure even if a smile can change history though.
>>
>>>
>>> As for how users interact with applications, if you think it's different
>>> on the web vs on the desktop, I would claim that you haven't finished
>>> generalizing your view of it. In either case the application presents
>>> something, the user responds, rinse-and-repeat. The main difference
>>> between a web-app and a desktop-app is the level of precision provided
>>> by the interface and the amount of latency. I've built web-apps that
>>> run equally well on the desktop. If you aren't aware of it, there is
>>> (or, was) a guy in the Windows world who sells a shareware product to
>>> facilitate writing desktop applications in PHP.
>>
>> But how it "runs" is different. A desktop app starts and has a message
>> loop that checks for user interaction. Responds and continues until
>> either program, user, or system terminates the processes. With the web
>> the php script receives its input via the web server, script runs and
>> does its stuff, creates the web page and terminates.
>>
>
> I guess you never worked much with state-driven applications, not
> everyone has. What we think of as a "desktop app" just sits there with
> its state-data in memory, and a "web app" reloads its state-data when
> another request comes in from the same user. Once the state data is
> re-established the internal processing is basically the same except for
> what subroutines are used to draw the "screen". In fact a "desktop app"
> doesn't keep its state-data in memory except conceptually unless the
> system is so lightly loaded that there's no thread-switching or swapping
> going on. Conceptually it generalizes to pretty much the same thing in
> either case.
>
> The "message loop" you speak of really isn't any different between a
> web-app and a desktop-app. For a desktop-app it looks like this,

Well sort of, where the web app has a web server in between and the
desktop has the OS,

>
> 1. application is entered on initiation
> 2. application presents initial display
> 4. application waits for input and is swapped out
> 5. user does something to cause an interrupt
> 6. application gets rescheduled as ready-to-run, swapped in
> 7. application scratches head, presents output
> 8. application goes back to (4) and gets "swapped out" again
>
> For a web-app it looks like this,
>
> 1. server starts up and eventually reaches idle state
> 2. a message comes in (analogous to 5 above)
> 3. application's state data gets reloaded as it's "swapped in"
> 4. application scratches head, presents output
> 5. application gets swapped out (state saved)
>

However with the desktop app it keeps running with a pid to the
instance, the web app does not. To keep continuity with a web app you
need to employ session mechanism. It need some sort of a login and
logout or it gets quite complicated with DBs and files. A simple example:

Application updated a simple file from user:

Desktop
1. App launches get pid
2. Locks file.
3. Reads file.
4. Displays file.
5. Waits for user input.
6. Writes updated file.
7. Removes lock
8. Program exits and pid is destroyed

Web:
1. Session created with user login
2) Web server calls script
locks file*
reads it
displays it
script ends
3) Web server waits for next request.
check session if same user goto 4 else 2
4) Get user edits
write file
remove lock*
script ends
5) User logout to remove session

*With a web app you would not lock the file from step 2-4 because if the
user left (close the browser, whatever) the session does not
automatically get destroyed the the desktop pid to run a cleanup to
unlock the file and such. You can have a session expire to auto logout
and such but it is not the same at all. With a desktop app it is real
easy to to insure only one instance, not so nor often desirable for web.


> It's pretty much the same thing, except that some websites don't do
> squat about saving state-data for an individual user. Some use PHP
> "session" stuff to do that, where a session identifier is a token coming
> in on each http request that allows that user's state-data to be
> reloaded for the request.

To emulate what happens in the desktop environment on the web is not so
easy.

> The loop is basically the same except that its "top" gets rolled around
> to the middle and given a different name. For a desktop-app the "top"
> is the guy hitting the enter key or clicking the mouse or whatever,
> that's the top of the "message loop". For a web-app the browser
> recognizes a link-click and sends an http request. It's the same thing
> unless you get fixated on the details to the point where you can't see
> the forest. Look an X Windows application in enough detail and you'll
> see the same basic process with a different protocol used between the
> client and the server. Steak or hamburger, it's all beef.
>


--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Problem with readdir and ssh2
Next Topic: web designers and developers
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Fri Nov 29 23:25:19 GMT 2024

Total time taken to generate the page: 0.04286 seconds