On Wed, Mar 4, 2009 at 5:31 AM, Dariusz Mazur <dar...@emadar.com> wrote:
> Prince Riley pisze:
>
>> Since the discussion in this thread has advanced pretty far along toward
>> recommending a FP and Powtils solution to you, then it appears you have a
>> technical answer from the group you can explore.
>>
>> However, without suggesting there is a bias in favor of a specific
>> client-centric vs server-centric web framework, the REST protocol has
>> succeeded in becoming a paradigm for writing web (client sever) apps.
>>
>> Primarily the reason why is -- especially for DB web applications -- is
>> efficiency, maintainability, and scalability. The recent major efforts by
>> Mozilla, Google, and others to improve the performance of browser Javascript
>> engines is due to their experience designing, writing and running CGI based
>> web applications. There is quite a bit of literature and discussion on the
>> web explaining why they are using REST versus CGI (Request/Response) which
>> you might find helpful in making your design choices.
>>
>> REST is bad choice for application , especially for this with much
> interaction with DB. REST is stateless. Are You see any desktop
> application, which is stateless?
> REST is good for simple catalogs, list of parts, etc. For sophisticated
> application this architecture has many limitation. Most of view depend of
> before user actions.
>
>
>
> --
> Darek
>
> Darek,
>
At the risk of sounding dismissive let me first point out that every one
of the application types mentioned in your list are DB applications. Perhaps
you meant to choose other examples to make your point. But unless the
catalogs and lists of parts are trivial and small, a software architect
wouldn't approach building a significant version of these kinds of
applications without using a DB.
Next, yes REST is stateless. But how does that work to prevent the level or
nature of the application data exchanges that flow between the client and
the server. Once a transaction is executed on the server by a REST protocol
message, the 'state' of the application's data isn't part of the protocol,
nor part of the message returned to the client when the request is
completed.
Let's use a more a representative example. Whenever a client refreshes the
data sent to it by the server, its a local copy; and it's that copy, not the
protocol, that is what is "stateful." The REST protocol would eliminate
fetches of rows or tuples from the server it does not need or those the
server has no reason to take note of or care about.. Likewise the server
would only send updates to the client which affected the 'state' of the
transaction that it fetched, for example a change in the row or column made
at the server's end of teh transaction.
But again, this is a change in the 'state' of the exchange and unless the
application's exchange/notification semantics which asked for notification
of ANY access to a tuple, even a simple READ, it received from the server.
Prince R
The REST protocol and the design frameworks built using it are used in
applications with significant DB application processing
>
>
>
> _______________________________________________
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
