Any recommendations on which library to use to create web enabled FPC apps?

Have found a few libraries and wonder if anyone has had good success with any of these or otheres.

So far I found
embeddable webserver
http://www.eilers.net/pascal
Site doesn't have much info

Synapse
http://www.ararat.cz/synapse/doku.php
Seems very low level.

Powtils
http://z505.com/powtils/idx.shtml
This one has a number of examples and seems the most promissing.

In our previous episode, Francisco Reyes said:

Have found a few libraries and wonder if anyone has had good success with any of these or otheres.

In the past I've had an Indy9 httpserver + ssl running. That was under Delphi, but parts of that I also had running (with indy10) under FreeBSD/32-bit.

It was based on the eliza example iirc.

Marco van de Voort wrote

It was based on the eliza example iirc.

URL/source?

Is the easiest way to go using FPC + apache with CGI?

In our previous episode, Francisco Reyes said:

> It was based on the eliza example iirc. URL/source?

http://www.indyproject.org there is stuff about indy in the wiki too.

Is the easiest way to go using FPC + apache with CGI?

Depends. For me that was not the easiest way, since the web part was only a minor part added to an existing application (an extra presentation layer so to speak), so I just added a HTTP server component.

It worked fine, but access was limited, so abuse/DDOS didn't have much chance.

Not fpc related, but irie pascal (http://www.irietools.com) has a pascal that is cross platform, and does handle web support quite well. My attempts to get him to support osx has fallen flat, but dos, windows, bsd, solaris (I think) and other distributions are supported, so it may do what you want.
If something like irie pascal could be built using fpc though, it would be a great help, since I'd really like to build some web apps, but w/o irie for osx, it puts a serious crimp in my ability to make cross-platform apps.
Fpc is cross platform I know, but as far as I know, it's not optomized for cgi execution like irie pascal is.
I suppose I could build a stripped-down version of fpc specifically for cgi-type work, if anyone is interested in such, but i like the approach irie took in that you could use the same compiled source on any of it's supported platforms.
I've thought about cloning irie pascal virtual machines and writing that in fpc, but I don't know if i want to do that much work just to get something that out to be simple to create if Mr.Stewart would pull his head out of his nether regions and allow somebody to make anyhow.

Travis,

I am joining this discussion fairly late so if you've found your solution already please ignore this post.

First, upon reading you feel Irie Pascal is 'optimized' for CGI execution on OSX (Leopard?) my first question is how are you defining that. I've looked over the Irie code just now (using the trial version) and I compared it to the Indy 9 component. So far I don't see anything that would suggest Irie's CGI could handle HTML requests any faster or handle larger loads better that the Indy components. Could you explain in a bit more detail what are you using as the baseline for your comparisons?

Next, could you also be a bit more specific if you are trying to write CGI components for an embedded web server or do you expect to run them under an standalone web server (like Apache)? Again just for the sake of understanding what options to recommend to you, the choices you outlined in your links all appear to be fairly common, ordinary web server add-ons that really rely more on what the CGI tolls calls (external process or a daemon) than something more exotic (like a DB server or transaction-based gateway).

Finally, give the advance from CGI based web apps to Web 2.0 (Javascript running in the browser) is there a design rational for running code on the server instead of in the web browser. If you want to see a few examples of this kind of web app check out Google Gears. Its just one of several web app frameworks that have become more stable and production ready in the past few years. Zend (which is PHP, not Javascript) is also an alternative.

In our previous episode, Travis Siegel said:

Fpc is cross platform I know, but as far as I know, it's not optomized for cgi execution like irie pascal is.

Interesting. Could you share your evaluation/comparison details? Maybe the people working on fpweb could learn something from it.

What is fpweb?

In our previous episode, Mark Emerson said:

What is fpweb?

Sorry, old name, nowadays it is fcl-web. See packages/

Travis Siegel wrote

Not fpc related, but irie pascal (http://www.irietools.com) has a pascal that is cross platform, and does handle web support quite well.

No Postgresql support listed... still seems pretty interesting.

Prince Riley wrote

Finally, give the advance from CGI based web apps to Web 2.0 (Javascript running in the browser) is there a design rational for running code on the server instead of in the web browser.

I think that is almost a religious war type of discussion... Short answer (as it applies to me at least) If all I am doing is getting data from a DB and displaying it in the browser, there is little reason to do Javascript.

past few years. Zend (which is PHP, not Javascript) is also an alternative.

Personally my preference would be
1- Pascal
2- Python
3- PHP

PHP can do absolutely everything I need/want; the difference is that I want something which lends itself more easily to well organized and structured coding. Also When I work on php it always feels like work.. even if it something I am doing for fun. It is one of those subjective things... the reason why there are so many languages and tools out there.

Marco van de Voort wrote

Sorry, old name, nowadays it is fcl-web. See packages/

Don't see it at
http://www.freepascal.org/packages

Is there where I should look?

In our previous episode, Francisco Reyes said:

In the source.

I'm interested to know why no one mentioned powtils yet (other than the original poster). I also am looking into writing a fairly complex CGI program and powtils seems very promising. And comments?

Never use custom embedded web server though it's not hard to build one.

Synapse http://www.ararat.cz/synapse/doku.php Seems very low level.

It looks more a TCP/IP suite classes to me.

Powtils

http://z505.com/powtils/idx.shtml This one has a number of examples and seems the most promissing.

This a pascal CGI unit.

Despite Powtils looks quite mature, especially the v1.6, the development is halted. It which IMO not too stable. I've been using it and produced some fairly complex CGI-based web apps. It does the job very well.

Another alternative is ExtPascal project (http://extpascal.googlecode.com). It offers a FCGI class and wrap ExtJS into Pascal language. You may build a RIA using it. I've been playing around with it for a while and already built an application based on it in production. So far, it performs very well.

Not fpc related, but irie pascal (http://www.irietools.com) has a pascal that is cross platform, and does handle web support quite well.

It's more or less similar to Powtils. I don't see any good reasons to use it while there are many CGI units available for FPC. Using Powtils, you don't need to worry about database support since FPC had support for almost any common databases out there. You don't need to worry about platform support either since FPC run on almost any common platforms out there. Plus, you get them all for free.

If something like irie pascal could be built using fpc though, it would be a great help, since I'd really like to build some web apps, but w/o irie for osx, it puts a serious crimp in my ability to make cross-platform apps.

FPC offers lot more. You want pascal scripting? You may use Pascal Script from RemObject. You want database support? You may use fcl-db (sql-db) or Zeos. You want CGI units? There are many, the most famous is Powtils. Etc. Plus, you can share your code with desktop application or may re-use code from your legacy desktop into a web based app without or with minor modifications.

Fpc is cross platform I know, but as far as I know, it's not optomized for cgi execution like irie pascal is.

Define "optimized for CGI execution". Most CGI units are just a handler for web requests that come from web server. Not much optimization you can do there. If you want more robust performance, go to FastCGI. FPC also has one for this: FCGI class from ExtPascal project.

I suppose I could build a stripped-down version of fpc specifically for cgi-type work, if anyone is interested in such, but i like the approach irie took in that you could use the same compiled source on any of it's supported platforms.

FPC is a general purpose compiler. What you need is a CGI or web framework that can be compiled by FPC. You don't need to do anything particular to FPC.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Francisco Reyes wrote

Any recommendations on which library to use to create web enabled FPC apps?

We have 4 applications in our company based on FPC + Powtils to generate standard CGI apps and so far it's working very well. Powtils also has some nice features like templates etc - though we don't use it in our projects yet. Other that the Powtils/PSP/??? name changes and finding a stable download, we have had no problems with it.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Andreas Berger wrote

I'm interested to know why no one mentioned powtils yet (other than the original poster).

I might be a bit late, but I just gave some comments on Powtils. :-)

I also am looking into writing a fairly complex CGI program and powtils seems very promising. And comments?

Our CGI apps are also fairly complex and even uses tiOPF framework, which is what our main GUI applications are based on. As I mentioned, other than finding a stable download, we have had no issues with Powtils.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Op maandag 02-03-2009 om 16:20 uur [tijdzone -0500], schreef Francisco Reyes:

It's part of the fcl, in Lazarus you can find and install it.

In this thread on the lazarus-forum I gave a simple introduction and you can find more information there:
http://forum.lazarus.freepascal.org/index.php/topic,6361.0.html

Joost

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.

I have not worked with Powtils so I can't discuss whether or not it has the features your application needs, or what the costs of using it might be in terms of server processing load (Web server Request/Response), response time, DB transaction processing load, etc. I also don't know whether it can be tweaked in some way to support the REST protocol for an application like yours.

One further point in this thread ... As a starting point in your thinking thru the design choices, here is a fairly complete but accessible article on the topic you might find helpful

http://www.ibm.com/developerworks/java/library/wa-ajaxarch/index.html

Op dinsdag 03-03-2009 om 12:30 uur [tijdzone -0600], schreef Prince Riley:

All those parties have a interest in trying to get as much as people using web-aplications.

But the key point in this is that people forget that javascript-programs are not meant to replace a full-blown desktopapplication.

What they say, in fact, is that building web-applications on the server side isn't a good idea. (They promoted it for years, and finally they have come to the insight that it doesn't work) So now they suggest to build a client-side web-application.

But the question they forget is: why would you want a web-application in that case anyway?!?!

Use a db-server and a desktop-application and all your problems are gone...

It's all so narrow-minded. If you have as a rule "thou shall develop web-based" all these things become important.

Web-based applications are usefull when you have users who only use your website now and then. In that case it does't matter much if one session takes some time on the server - unless you are google, offcourse. (But also large community-sites now are releasing desktop-clients)

If users use the application constantly, don't use a web-application.

So the things explained in this document from IBM is usefull for very large systems which a lot of users (Like Amazon, but they also don't like the idea of a full-blown javascript application) or some idiots who do things in a web-application while they shoudn't.

Joost.

I disagree. I think a migration to web based software development offers many benefits over desktop software. Instant deployment, and Object Orientated JS via ProtoType is completely doable. And if you find bugs or memory leaks I'm sure they'll get worked out in the next revision.

I've done some awesome Realtime Apps with my custom Information Server (built in Dephi) for the backend, and HTML/CSS/JS for the front.

Let's not forget the promise of Cloud Computing and its benefits as well.

I've heard all this before since 10 years, and it is only true for small applets used by a broad public.

For large applications (1500+ windows) that stay open virtually all day and are used by a specialized public, the benefits of web-based are zero, and are even contraproductive. They mostly clog the server with code designed solely to maintain some form of user session state on the server.

The sole advantage of web apps is ease of distrubution. It is countered by the fact that there are still many non-compliant browsers out there. (or you could require version X of browser Y, but then you're back in c/s territory)

To prove my point I once did performance tests with AJAX, SOAP and whatnot technologies when compared to a specialized C/S protocol. In general the conclusion was that SOAP and standards-based applications worked 6 times slower. Also something to take into consideration, because it meant that 6 times more people could work on a single server simultaneously.

Michael.

That might be true using conventional servers for the back-end but the apps I did and tested were developed on MY back-end. When tested - I was pushing about 35k simultaneous connections (sustained) with jumps up to 45k per network node. Each connection was spanned across HTTP,POP3, and SMTP :-) All protocols mentioned were running on the SAME machine. Each connection had access to MySQL connectivity via my own n-Tier Database API that could handle the thread pooling required to handle such transactions.

This technology is something I am looking to bring to Lazarus and open up for Cloud computing sometime soon.

Joost

Reading the responses on this discussion thread, it appears the 'religious war' you mentioned in your prior post was unavoidable.

Not to add any fuel to the warring opinions I'd like answer a comment you made in response to my response.

The recent push to make web applications (not simply web browsing) perform more like desktop applications has been the primary driver behind the Web 2.0 and the improved Javascript engines by Google and the Mozilla people. They have their own commercial motivations for those improvements, the primary driver has been the software application developers who want web apps to perform like desktop ones.

While several traditional "desktop" application scenarios do still exists that will likely always run directly on the O/S without a web client front end, the direction of most major software application development efforts I've witnessed in the past three years have all targeted migrating the desktop GUI over to a web browser. Others in the discussion thread have referenced several reasons for this shift already, but the trends continue to follow the idea of pushing as much of the presentation and processing layers onto the remote web browser.

Finally, respectfully I must disagree with your comments that the applications deployment approach " is only true for small applets used by a broad public. " ignores the TOC and other economies of scale afforded by portable web applications. Scott Trade and TD Ameritrade are just two of several examples where sophisticated trading desk and customer centric web-based applications are running on 100,000s of web browsers. Just a few years ago these same applications were shipped to clients and had to be installed and run on their desktop PCs.

But what irie pascal offers is the ability to compile my code once, then execute it on any of the supported platforms. Fpc can't do that.
It's really a matter of preference, I know, but it's kind of a moot point, since Stewart King has clearly stated there is no intent to support osx, and since that's my main platform these days, it just means I have to maintain separate systems to compile fpc executables for all os types I want to support.
Again, not a major issue, since testing needs done on all the given platforms anyhow, but I just liked the write once, run anywhere approach.
And the fact that it's not java (for me at least) was another plus. Not that there's anything wrong with java, I've used it too, but pascal just happens to be my favorite language, and anything that makes it possible to have portable code w/o my having to put in extra work is a big plus.
However, I'm really not doing as much cross-platform development as I used to anyhow, so there again is another point, I'm just saying that for me at least, (for a time) irie pascal filled a very real need, and if fpc could be built like that, I'm sure I'm not the only one who could benefit from it.
(fpc virtual machine project anyone?) :-).

I used to be on your side a few years ago, Joost. But now I can fully understand why many people start to migrating to web based applications. Especially when your application is used round across the globe or across the nation.

But the key point in this is that people forget that javascript-programs are not meant to replace a full-blown desktopapplication.

It was the case a few years ago. But, today it doesn't too hard to replace a full-blown desktop application with a web based one with exact user interactivity experience (drag-n-drop, fast response, rich UI controls, etc). Just take a look what current JS framework are now offering e.g. extjs, qooxdoo, jquery, etc. A web-based application that lack of user interactivity is yesterday story.

Use a db-server and a desktop-application and all your problems are gone...

It's not as simple as that. Everybody knows that deploying a desktop application isn't a fire-and-forget action. There are some problems as well in that area that can be minimized by using a web-based application. I believe you know that as well. :)

I disagree. If google can do it, why can't we? When SAAS becomes more and more demanded, web-based applications would come into play and become more and more important. When we're talking SAAS, users could use the application all day long.

So the things explained in this document from IBM is usefull for very large systems which a lot of users (Like Amazon, but they also don't like the idea of a full-blown javascript application) or some idiots who do things in a web-application while they shoudn't.

Today web technologies are getting more advanced, internet connection is getting cheaper, browsers performance are getting better, web standards are getting more obeyed, and client machines are getting faster. So, making a full-blown web-based application isn't idiocy. However, I agree that not every kind of applications should become web-based. There are some area where desktop applications could do the job better and can't be replaced by web-based application. ;)

I've heard all this before since 10 years, and it is only true for small applets used by a broad public.

10 years ago, people was just talking about it. Today, they're doing it. C'mon, look around, there are thousands of complex applications provided on the web. Not to mention, web-based applications in closed environment which can't be accessed through public internet.

The sole advantage of web apps is ease of distrubution. It is countered by the fact that there are still many non-compliant browsers out there. (or you could require version X of browser Y, but then you're back in c/s territory)

Actually, it's nothing different to FPC that providing code generator for different platforms. And browser incompatibility is no longer an issue if you're using JS framework which hide all the differences so you just need to use same API for any browsers.

Performance isn't the only important things. I believe we all know that. ;)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Again, not a major issue, since testing needs done on all the given platforms anyhow, but I just liked the write once, run anywhere approach.

If you really need that, despite you said it's not a major issue, then you should consider other solutions. FPC is simply not for the purpose. FPC is about "write once compile anywhere" since FPC generates native code for each platform. Actually, with a bit of effort, you could make a build machine that would (cross)-compile your source code to any platforms by a single command.

Not that there's anything wrong with java, I've used it too, but pascal just happens to be my favorite language, and anything that makes it possible to have portable code w/o my having to put in extra work is a big plus.

So far, FPC is quite portable to me. When you write your code right, targeting another platform is simply recompile the code. Since FPC is fast, doing that requires just a few seconds, or minutes is the application is ultra huge. To me, it's not an "extra" work. Besides, when you're working on server side, it should be less platform you need to support compare to if you're working on client side.

(fpc virtual machine project anyone?) :-).

Consider Delphi Prism if you do like pascal language. ;)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Many people on the "desktop" side keep saying that web-based app is *always* slow, cumbersome, and unresponsive, while many people on the "web-based" side keep saying the otherwise. If each insists on their own POV without trying to understand the other POV, and ignoring facts (success/fail stories) and consequences (dis/advantages) of each POV, then it becomes a religion war. I'm not interested in such discussion.

Nevertheless, let's see what the future trend for software development will goes. ;) Anyway, whatever the trend might goes, I already have the solution: FPC and Lazarus. Maybe we can agree on this one. :D

Sorry, but I can't help myself. I can hardly think of a significant web app I have enjoyed using.

Ah, unlucky you. :)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Well, drop by and I'll prove to you - hands down - that what our clients need simply cannot be done by web applications, because they cannot interact with the local desktop. Can your web-app burn a CD-ROM ? Does it have access to a smartcard reader ? Can it start and control MS-Word ? Can you drop files on it to send to the server ? I thought not, unless maybe you develop in Java, and then you are back in C/S...

And finally: can these apps work offline with NO internet connection ? I don't think so.

Web apps: by all means, but not for every possible scenario...

Michael.

Maybe this will convince you:
There was a comparison between our software and software for the same purpose, but written in web (written by a competitor). It was evaluated by end-users and by a team of computer savvy 'experts'. An important point in their testing was responsiveness. Both teams gave us more than double the score of the web-app.

I'm not saying that web-apps are evil, but simply that they are not the solution for *every* problem.

Michael.

Well, we all know that those kind of applications which requires full access to local machine can't be replaced by web-based apps. That's where desktop app shows its power. You don't need to prove anything. :)

And finally: can these apps work offline with NO internet connection ? I don't think so.

I've been playing around with (Google) Gears and (Yahoo) BrowserPlus. Somehow web-based app could be made to work offline during no internet connection available and then do synchronization after internet connection available. So, it's possible, if it's really needed.

Web apps: by all means, but not for every possible scenario...

Exactly! I believe all web app developers realize that web-based app is never meant to do *every* scenarios. But, there are some cases which web app suit the scenario very well, in some cases, it's even the only way. The same thing also goes for desktop app. And, in some cases, we need to combine both to get the best of each. ;)

So, let's us respect each other decision to whether go web or not. Let's assume s/he knows what s/he is doing and the consequences. Now, let's stop this web-or-desktop things and focus again to the topic of this thread. Agree?

100%

Michael.

Op dinsdag 03-03-2009 om 16:17 uur [tijdzone -0600], schreef Prince Riley:

Reading the responses on this discussion thread, it appears the 'religious war' you mentioned in your prior post was unavoidable.

Tha wasn't my comment. But now I realise that it was me that started this... What have I done, well, it's fpc-pascal... so it must be possible.

So because everybody else does it, it's the right way to go? I think the trend will stop. One of the signs are the web-communities who are developing destkop-clients for their community now. (Was it hives?)

Well, if you would make the application 'REST' it would simply mean that you distribute the application to the user-desktop every time you run it. How can that be easier then distributing it once?!?

All you need is an single executable (or maybe even interpreted) and a system to distribute through the web. Other then distributing it on every use, as is done now.

That we are in the IT-world as it is now, everything web-based, is based on political reasons and not technical reasons.

Joost.

Op dinsdag 03-03-2009 om 14:50 uur [tijdzone -0600], schreef Andrew Brunner:

Well, I only see one, and that is the deployment.

Now imagine that all efforts that has been put in developing ajax-like technologies were put in building a good web-based distribution system. something like: "click here to run this program on your desktop" and then build a safe environment on the desktop to run the application and add it to the menu if the user want so he can start it again.

Problem is that only Microsoft can introduce something like this. And they would have done it, when their .NET technology woudn't have taken over the web.

Joost.

Joost van der Sluis wrote on wo, 04 mrt 2009:

Google did that with their Google Native Client:
http://code.google.com/p/nativeclient/

Anyway, I think this discussion has become more suited to fpc-other than fpc-pascal, so I'd like to ask everyone to follow up there when discussing about "web-apps are good or evil". Questions/answers about implementing web-apps in FPC can of course remain here.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Hello Francisco,

I use the following for my applications:

- synapse with visualsynapse ( I modified visualsynapse to perform Keep-Alive http connections)
- HaXe/Neko for remoting (www.haxe.org) - very easy to use ! same language for client/ server/ flash

I have created a pascal framework for embedding neko modules in pascal applications, which can be found at http://code.google.com/p/pascal4neko/ the modified version of visualsynapse can also be found there.

Cheers,

Adrian.

I've made this size of application. And now develop it for desktop and webbase. Whole application is made only one and compile to both destination by FPC.
Both version can work together on the same database. And web-base work quite fast. Much of response is done <100ms on short distance (in the same LAN). Long is 200ms worse.
Small part on http://emadar.eu:8001 but its only Polish.

this is animation how it work:
http://www.emadar.com/fpc/fakturowaniemobile.gif

I will publish source as open source. I've prepare demo of our framework, but till now any dos is absent.
If anybody interested I send links.

They mostly clog the server with code designed solely to maintain some form of user session state on the server.

Of course. But opposite solution is terminal (like NX or Microsoft Terminal Server) which work the same.

The sole advantage of web apps is ease of distrubution.

Not only.
First we can access form everywhere. Long distance is not problem. Second is easier to install and first access for new user. Every can type URL in browser, but very often desktop application interact with other programs in computer and something not work. Third: users don't lost data. Others are less important.

Our solution work on most browsers.

Its not comparable. We send quite different information. On C/S we send data, for browser send screen (of course write in HTML source). Size of screen is const, but in huge application data transfer grow. Not all can be don on RDBMS server

Prince Riley pisze:

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.

Yes, please do. I'm always interested in learning.

Michael.

Michael Van Canneyt pisze:

http://www.emadar.com/fpc/xwebdemo.zip

Its contain CSS, majn JS script, framework , embedded server HTTP and demo with one form.
It imitate near whole basic API of VCL with tForm, tEdit, tButton and (more important) form navigation, modal form, keyboard and mouse events handling, message queue for Wndproc and so on. Application work in own thread, whole time the same apart of communication with browser.That is very similar environment for running application, as on win desktop.

As I write, its only source without manual and comment. It was prepare to Polish audience.
But fell free to ask, i try to explain how it use.

Can your web-app burn a CD-ROM ? Does it have access to a smartcard reader ? Can it start and control MS-Word ? Can you drop files on it to send to the server ?

For the sake of clarification let me ask you if its your position that web-apps are limited due to the fact that they are not hosted on a systems H/D and loaded into memory by the O/S in response to a mouse click or a keyboard type in? Is the distinction you are making here between a web-app and a desktop (installed application) based on your understanding that a web-app interface cannot drive and launch local installed hardware and software.? If that's your presumption, and I hope I am mistaken in saying that it is, then let me answer affirmatively .. to each question.. YES , they can.

Leaving aside the security implications and the issue of specific hardware capability, Sun Microsystems Java Platform, especially its HotSpot installer/environment can do nearly all the things you have mentioned with very few exceptions.

Likewise, with some modifications, the new JavaScript engines and the applications being written and released by Mozilla, Google, Amazon, to run on them can all but replace the entire MS Office Suite. In less than two years, the entire Win32 GUI and service API will be a web-application based entirely on thee .NET framework ( just download Windows 7).

Five years ago, Steve Ballmer even announced that the future architecture of the Windows desktop application and O/S system platform would be to migrate toward web-hosted applications consisting of web-deployed components.

He was later even more clear on this point stating that future releases of the Windows OS and application suite would not be pre-installed on new desktop PCs, but provided via the web on SOA as leased-licensed products. In essence, the desktop machines workhorse applications with notable few exceptions would all be web-apps.

Python, another web-app language, can run MS Office applications using COM/DCOM. without any drag, drop, or click. So unless I am missing the point you are making entirely, and mistaken about the scenarios you mention here, the answer to your questions are yes and yes.

However. if you asking whether a web app can start a CD burning program (like Nero) on a remote user machine? The answer is absolutely yes. But can a web-app physically open the CD tray and insert the CD-RW media .. no, but neither can any desktop application or any C/Sapplication.

Can a web-app take the data from a smart card reader attached to the system .. again yes it's not a problem whatsoever.. done all day, every day, all over the world. Can a web-app physically put a Smart card into a reader .. no, it can't; but neither can a desktop application or any C/S application.

Can a web-app transparently without user intervention start a MS-Word application, open files, and do editing on a file .. yes again. In fact, this is done now with such regularity its almost trivial. If you haven't seen such web-apps you need only take a look at the archives on the Microsoft knowledge base for articles on Automation and on DCOM.

At one point there was such a substantial amount of these capabilities included into the MS Windows OS, and built directly into the windows desktop explorer and the Internet Explorer to support application automation that it created a security nightmare few sysadmins realized or appreciated.

Finally, you asked ...

And finally: can these apps work offline with NO internet connection ? I don't think so.

The answer to your question whether a web-app can work without a Internet (please insert the word "network" here) connection is no but can a C/S application work without a network connection .. same answer .. no.

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

Prince Riley wrote

<snip a lot of non freepascal things>

Wasn't this thread supposed to be continued on fpc-other? If you are ignorant: http://www.hu.freepascal.org/mailman/listinfo/fpc-other/

Vincent