Re: approaches to PHP-based application interface? [message #176732 is a reply to message #176730] |
Fri, 20 January 2012 12:13 |
Erwin Moller
Messages: 228 Registered: September 2010
Karma:
|
Senior Member |
|
|
On 1/20/2012 12:34 PM, The Natural Philosopher wrote:
> Erwin Moller wrote:
>> On 1/20/2012 12:04 PM, The Natural Philosopher wrote:
>>> Erwin Moller wrote:
>>>> On 1/20/2012 11:05 AM, M. Strobel wrote:
>>>> > Am 20.01.2012 10:43, schrieb crankypuss:
>>>>
>>>> <snip>
>>>>
>>>> >> Thank you for your opinion, but I've done "true GUI programming" and
>>>> >> I've had a
>>>> >> bellyful of talking paper-clips and wiggling icons.
>>>> >
>>>> > Yeah. But the forced limitations in web design is not the solution.
>>>>
>>>> Hi Strobel,
>>>>
>>>> You cannot say that in such general terms.
>>>> If you are fluent in PHP and web-related technics, it is very tempting
>>>> to want more and develop desktop-apps using those technologies.
>>>> I know I want to.
>>>> Comparing them to slow M$ stuff makes no sense.
>>>> M$ seldom do things right.
>>>>
>>>
>>>
>>> Look in philosophical terms what you are saying here is more or less 'I
>>> want to use a browser and associated web server as my GUI API rather
>>> than the underlying native GUI API'
>>>
>>
>> Exactly.
>> That is exactly what I am saying.
>>
>>
>>>
>>> Which is all fine and dandy if that GUI suits the application.
>>
>> Of course.
>> That goes without saying, I presumed.
>> If it didn't another approach would be advisable.
>>
>>>
>>> And is one accepts platform independent and WAN ready from the word
>>> 'go'.
>>>
>>> BUT is not always the optimal paradigm, and usually means writing in
>>> rather badly implemented and poor languages, that are deliberately
>>> crippled for security reasons - javascript/PHP and the like.
>>
>> "optimal paradigm" can mean anything, depending on the situation.
>> In case you need speed: Go C(++), or even assembly, and write smart
>> fast code.
>> In case you need supersmall memory footprint (like sometimes in
>> embedded software): Go assembly.
>> In case you want a very high level to approach a problem: Throw in
>> some framework, or do it yourself in some high level language.
>> etc.etc.
>>
>> And I do not understand why you deem PHP a "deliberately crippled
>> language for security reasons", because it isn't.
>>
>
> well in the sense that apache or whatever invokes it with apaches own
> privileges and the concept of a users own privileges is not inherent in it.
>
If you want PHP to run with different privileges/as another user, set it
up like that.
You wrote: "the concept of a users own privileges is not inherent in it"
Do you mean by user the visitor of some website? I hope not, because
that would make no sense at all.
If you mean the privileges for the PHP process under Apache, set it up
like that.
>
>
>> Also, Javascript isn't crippled at all.
>
> Perhaps you need to write more of it. It cannot access much at all. It
> has no concept of full system access.
>
> It cant even access a local printer..
From a browser? No, not directly (luckily and by design).
>
>> I think you are confusing Javascript implementation in browsers with
>> the language itself.
>> Of course the browser must "cripple" the language by not exposing
>> everything on the computer to the language.
>>
>
> Of course thats what I mean. The language on its own as an intellectual
> abstraction is as worthless as piece of used toilet paper when what you
> have is a browser running (a usually highly buggy) implemenation of it.
Maybe you should broaden your horizon a little.
Serverside javascript:
http://nodejs.org/docs/latest/api/all.html
Javascript (ECMAscript actually, contact our friend PointedEars for
details) isn't limited to a browser.
It is a language that can bind-to, manipulate, etc objects that are
exposed to it by the environment it is in.
>
>> Your way of thinking is like saying: "No animal can fly because I know
>> of a dog who cannot fly."
>> Javascript isn't a crippled language. It's implementation is browsers
>> is (luckily) "crippled". Big difference.
>>
>
> No, My stance is more 'pigs may fly, in theory, but I have yet to find
> one that did'
Then look at nodejs to see your "flying pig".
(It wasn't a pig in the first place in my opinion.)
>
>>
>>>
>>> That's not to say you can't write web apps but it is possibly making a
>>> rod for your own back if you do.
>>
>> I am not sure what you mean by that.
>>
>
> I am saying that when all you decide to use is a hammer, you may find
> watchmaking a difficult task.
Indeed it would be difficult, probably impossible.
But that isn't relevant.
Using the power of PHP/HTML/Javascript combination as a desktop
application would be great in my opinion, and that was what we were
discussing, I thought.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|