Hello:

I want to ask (and know) if i can use apache-tomcat to serve servlets developed with freepascal. If not, is there a similar server for fpc? Note that i want/need servlet like in java and other languages, not a propetary format or cgi or anyother.

P.S. Yes, i have googled but for servlet freepascal i found references to THttpServlet and i already use it/them, or references to java servlets.

TIA

------------------------------------------------------------------------------------- One reason that life is complex is that it has a real part and an imaginary part
-Andrew Koenig

Eduardo, the short answer is no, it wouldn't work. Tomcat doesn't understand binary files, it only "executes" Java classes.

Your options are:

1) CGI.
2) Apache Modules.
3) Your own web server.

Leonardo M. Ramé
http://leonardorame.blogspot.com

you wrote

Eduardo, the short answer is no, it wouldn't work. Tomcat doesn't understand binary files, it only "executes" Java classes. Your options are: 1) CGI. 2) Apache Modules. 3) Your own web server.

I will opt for the 3rd. then. All in pascal of course and free...

Leonardo M. Ramé http://leonardorame.blogspot.com ---

Thanks again Leonardo

Eduardo, I made an example (a couple of years ago) of what you're trying to do:

http://leonardorame.blogspot.com/2007_04_01_archive.html

Leonardo M. Ramé
http://leonardorame.blogspot.com

Maybe you want to and
http://code.google.com/p/pascal4neko/

I am using the new haxe language to build neko modules, which are running in the visual synapse webserver written in pascal. At the pascal4neko website is a modified version of the webserver, which is able to run neko module in a compatible way of the mod_neko apache module described here: http://haxe.org/doc and here http://nekovm.org/doc/mod_neko

Using haxe for web applications is very effective, because you use the same language for back-end and front-end. With pascal4neko you can use your existing pascal code or use pascal for low level tasks.

Hope this helps.

Cheers, Adrian.

Using haxe for web applications is very effective, because you use the same language for back-end and front-end. With pascal4neko you can use your existing pascal code or use pascal for low level tasks.

Have you heard about ExtPascal? It wraps ExtJS library into Pascal unit so you can use ExtJS as if you're using V/LCL components. Powtils also has PasJS which could compile your pascal code into JS, though it only supports very basic of pascal language. Unfortunately, both project seems to be stalled. :(

Have you heard about Morfik? I think this one is better than haXe since it directly produces native code from *pascal* code, both for server and client side.

Aha. The pasjs might be interesting, I'm looking for a pascal-to-javascript converter...

Have you heard about Morfik? I think this one is better than haXe since it directly produces native code from *pascal* code, both for server and client side.

And this is why I need the pascal-to-javascript converter... :-)

Michael.

I have seen ExtPascal and looked at the ExtJS library which seemed interesting, but if I am right the license is not LGPL or something similar. Same with Morfik interesting, but expensive and not open. Haxe is opensource and, if you are used to pascal like me since 30 years now, as a language not so far away (at least from all C - styled languages the most comfortable in my point of view).

I have never heard of Powtils but will take a ,

Adrian.

And this is why I need the pascal-to-javascript converter... :-)

Don't you have access to Morfik's JST technology? ;) Anyway, glad to hear you interested to PasJS, you may get the source code from Powtils' SVN (at googlecode). I hope you can continue the effort, or better, join also with ExtPascal project. :D Both Powtils (with its PasJS) and ExtPascal (with its FCGI) have good future if both development isn't stalled or have more support from other pascal developers. :(

I have seen ExtPascal and looked at the ExtJS library which seemed interesting, but if I am right the license is not LGPL or something similar.

If you understand the parser code which generate the wrapper units, you may able to enhance it to be able to parse other JS UI frameworks. Qooxdoo seems to be another good alternative for ExtJS. ;)

Same with Morfik interesting, but expensive and not open. Haxe is opensource and, if you are used to pascal like me since 30 years now, as a language not so far away (at least from all C - styled languages the most comfortable in my point of view).

I'm not quite interested since it produces intermediate code which need to be compiled by other compiler. If it has some serious bugs on the code generator, it would double my work. I prefer Powtils, ExtPascal, or Morfik approach, otherwise I better go to Java and GWT.

I have never heard of Powtils but will take a 's yet another CGI library for Pascal. You may check it out from

http://powtils.googlecode.com. It used to be known as Pascal Server Page.

please excuse my ignorance, but I have a question I need to ask from long time:

why is Java fit to create a web application and Pascal is not ?

Why does one need to translate from Pascal to Java ?

Thank you

Duilio Foschi

duilio foschi wrote

please excuse my ignorance, but I have a question I need to ask from long time: why is Java fit to create a web application and Pascal is not ?

There is no inherent reason why Java is fit to create a web-application and pascal is not :-)

(in fact, I don't think Java is fit to create any application, but that is another discussion, which is not on it's place here ;) )

Why does one need to translate from Pascal to Java ?

Not from pascal to Java, but to Javascript: The browsers only understand javascript. Translating pascal to Javascript means you can write browser-side code in pascal, and then send it to the browser.

This is why I think Morfik has the right approach: They allow you to code both server and client-side in Pascal (or VB). The server code is compiled to a super-fast server binary, the client code is sent to the browser as Javascript. Google does something similar with GWT, only they use Java. (but Morfik was the first to do it, and they hold the patent on this technique).

My (long-term) plan is to make this possible in Lazarus. The server-side is more or less covered, the basic blocks are in place. The client-side needs still some work, of course.

Michael.

why is Java fit to create a web application and Pascal is not ?

Who did say (in this thread) that Pascal doesn't fit to create web applications? I've been making tens of web application using Pascal. Since first time I made my own CGI wrapper unit, then migrated to Powtils because it has more useful functions than mine, then now using FastCGI from ExtPascal. I've been advocating many pascal/delphi programmers to stay in pascal for web programming, and to my surprise, many pascal/delphi programmers don't know that pascal is able to do that! Most of them think that web programming is only can be done using PHP, ASP, or Java. :(

Why  does one need to translate from Pascal to Java ?

We're talking about JavaScript, not Java. And Java JavaScript though both has similar name and syntax.

(in fact, I don't think Java is fit to create any application, but that is another discussion, which is not on it's place here ;) )

Hahahaha... unfortunately, there are more Java frameworks out there than Pascal which became very handy for anyone to build complex applications. Performance and dependency are not priority to these people. Yes, I know we can make any of those frameworks by ourselves. But not everybody is as expert as you are, Michael. ;)

This is why I think Morfik has the right approach: They allow you to code both server and client-side in Pascal (or VB). The server code is compiled to a super-fast server binary, the client code is sent to the browser as Javascript.

I agree with you on this. If Morfik has support for FastCGI, I wouldn't mind to purchase a license. :)

My (long-term) plan is to make this possible in Lazarus. The server-side is more or less covered, the basic blocks are in place. The client-side needs still some work, of course.

Great news! If it can be as another "widget" for Lazarus, it would be better. Someone from ExtPascal had done some effort writing a .dfm/.lfm convertor into ExtJS window. As the other efforts, it's still far from perfect. Unfortunately his demo site seemed to be down (http://reidspace.co.uk:6464/).

There are many pascal project for web programming out there, too bad each walks on in its own exclusive way and never got finished. If there's someone who able to combine or synergy those projects, maybe now we already have a complete web framework for pascal.

I'm dreaming that someday there would be a complete pascal framework for web programming, with these features:
- server side module that supports Apache module, persistent CGI (TSR) using pipe, and FastCGI using socket (they are all already available, just need to be integrated).
- communication module that supports any web service protocols (some are already done).
- client side module that supports pascal-to-js compiler (can be started from Powtil's PasJS?).
- tools to wrap external JS UI library (at least the famous ones) and integrate it with the PasJS compiler (as ExtGWT, can be started from ExtPascal's converter?).
- server side scripting module for dynamic programming (can be started from RO's PascalScripts?).
- an IDE to build the UI and support event-driven programming (can be started as Lazarus plugin?).
- (optional) tool to convert desktop application into web application utilizing all the above features.

So, most of them are already available though partially and separately. If there would be a voluntary but dedicated developer team to focus on this, we may already have them within 2-3 years? :D

Well, I have a license. Money well spent, all things considered :-)

More or less all this is the ultimate intention. Whether it will be realized is another matter. But there is hope: I still remember the days when something like Lazarus was a distant dream, and now I've completed and deployed my first Lazarus-developed commercial application...

Michael.

May I ask when do You need write ordinal code parallel on browser and server side? What kind of computation? For me 99% of code should be on server. As You write we have very fast (because compiled) application on server. Each user action can be transform to server, computed and results sand back to browser. Only for critical section we should write JS script. GUI is write once, independent (as ExtJS)

May I ask when do You need write ordinal code parallel on browser and server side? What kind of computation? For me 99% of code should be on server. As You write we have very fast (because compiled) application on server.

Fast is relative. You may have a very good and fast algorithm on server, but you got bad network infrastructure, it'll look slow to the client. You may have a very poor algorithm on JS code, but you got good network infrastructure, and most of the clients are using high-end machine, it'll look quite fast to the client. Most clients would never care whether you put the code in server or in browser, the just want to use your application with acceptable and reasonable performance.

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.

Of course, nobody would prevent you to do all the computation on the server side. But IMO you'll waste resources on the client side that you may utilize. Though it doesn't seem to be significant when you look at a single client, but when you got thousands of clients connected, you would save significant resources on the server side.

Each user action can be transform to server, computed and results sand back to browser. Only for critical section we should write JS script. GUI is write once, independent (as ExtJS)

GUI may write once. But you could have more than just GUI on current JS frameworks and browser capabilities. Though it's not easy, but it's possible now to create a very complex desktop-like application on browser with acceptable performance. I never thought that I would see chess game to be completely running under browser using JS (no flash, no plugins, no applets, no server side logic is required). But it's common to see it or other kind of games under browser nowadays (with most or all of game logic resides on the browser side).

Most clients would never care whether you put the code in server or in browser, the just want to use your application with acceptable and reasonable performance.

I do care because for security reasons I have switched off scripting at all (with FireFox NoScript plugin). I ignore all web pages that insist on javascript so it does matter.

Jürgen Hestermann.

I want to write my client-side GUI code in pascal. I have no wish to learn Javascript. All extensive computation (mostly queries and database stuff) happens on the server, but the GUI must be programmed in Javascript because that is all the browser understands.

Michael.

I want to write my client-side GUI code in pascal. I have no wish to learn Javascript.

But, writing a pascal-to-js compiler obligates you to master JS as well. Otherwise, you won't be able to generate correct and optimized JS codes. If you can't keep the motivation up, you'll end up writing JS directly instead of continuing the PasJS compiler development. This case that happened to Script# project (C# to JS compiler). :D

I should have written 'I have no wish to start programming in JavaScript' If I am going to have to write the converter, then obviously I'll have to learn it :)

Michael.

Michael Van Canneyt pisze:

Yes, You have to had client-side write in JS. But its not so huge as You imagine.
But maybe I dont understand your need.
You think about counterpart of LCL level, or computation wide consist in event (form.onclick, form.onedit) function in Delphi ?

All You need is simple manipulation of HTML: change innerHTML, innerStyle and traverse trough DOM tree. Today I have less than 1k LOC, if future will be twice as grow. With this most of widgets ans its behavior can be achieved.
Most of work is done by CSS, which is static. And this is no place do translate pascal to JS

Second stage I don't move to browser side. For me it will be very big mistake.

All events and almost any class I need should be available in the client...

Michael.

Michael Van Canneyt pisze:

What for?
You want to move 20% of application to browser. And you think that will be faster? more flexible?
will work on most browsers?
I dont think so.

Bee pisze:

Poor algorithm on JS will run very slow (computation made by interpreter never will be so fast as compiled), huge program on JS run no fast and (more important) load slow. Infrastructure is important, but its rather easy have delay less than 200ms, thats enough to proper work. On other side you have to communicate browser-server not so rare.

Yes. Im quite impressive about new features of CSS3 and HTML5, but it has nothing to putting computation to browser side.

To make beautiful site you need generate only several kb of html code, when you transmit it compressed or differential it took only one frame. Computation on server side took less than 2 ms.

Browser should resolve DOM, CSS, SVG ets. it enough to work Animation can be done in several lines of JS, you need transfer orders in 1..3 per second frequency

Chess is very simple (of course on GUI side). Today I can imagine, that is only few lines of code to display beautiful play desk. To manipulate this code I dont need ane new JS code;

I write about translate near every function from pascal to JS. Of course some of specialized part is need to be write on browser side, but only few. Similar as sometime we write small part of application in assembler.

In our previous episode, Michael Van Canneyt said:

Aren't you talking about two different classes? Webapps with some browser (Ajax) support, and more RIA-like JS apps?

At least that is how it sounds to me, with Michael going more to the RIA direction.

What I want doesn't matter. Our clients want rich web 2.0 webapps.

I just want to make them in pascal and keep the codebase and know-how I have in my team.

If it was up to me, client/server would do the job just fine. But I cannot ask all parents of all pupils of all our schools to install a client application:
a) They don't want it. They are mostly computer agnostic, but they can surf the internet. b) Our helpdesk would find and emigrate to an unknown island somewhere in the south pacific because of the installation and upgrade problems :-)

Michael.

Exactly.

But as soon as you do RIA, you need business logic on the client. Sad, but true.

Michael.

Marco van de Voort pisze:

I don't talk about any compromise with appearance of application. Everything, as you imagine should be done with HTML+CSS. I dont think (I testing it every day) that is any bigger issue, that can't be done on server side with small JS addons on browser. RIA means for users beautiful, with 3D, alfa and animations efect. All can be done with small assistance of JS.

And I ask once more: what kind of GUI, which elements/behaviors cant be done without 100% assistance of JS.

Many of us know that java application are slower than Delphi/Pascal. Why do you think that JS will be different.

This is a position that I have not been able to understand for several years now.

(Since Delphi can easily create self-contained, install-less applications, I'm assuming FPC can as well.) So why not create a link on the web site, where the users start, that downloads the program and runs it. The program then talks TCP/IP direct to an application server to get all data just like it would talk to a web server.

No installation required. This is what Java Web Start is all about and it works really, really well. You can do the same thing.

I believe the only reason customers ask for browser-based RIA is that is the only choice they are familiar with because the media are all abuzz about it. Other, better choices have been around for a long time that solve the same problem.

That's the point - how do you define small ?!?

If you can't do everything on the server, you have to perform some part of the logic on the client. And the richer the client gets, the more logic has to be performed on the client. Now you have the choice:

1. do the small part in JS - with the knowledge, that this part will likely increase in the future
2. or look for an alternative language, which is as close to what you are used to program as possible

My decision is clear, after some hours hunting a bug, because i declared a var "id" and somewhere made a test against "Id". I am using the haxe to JS compiler, because its typesafe. If there were a pascal to JS compiler, it would be an option to. But I doubt, that is feasible to convert the libraries to work under that environment. And that's the next problem. A language is only as good as its supporting libraries.

Cheers,

Adrian.

Michael Van Canneyt pisze:

that is no problem at all, I can prepare every site as want, But problem is: internet application should have the same behavior as desktop or better, not less in any point.
Do you try to achieve browser key: back and reload aware without communicate with server.
And what about keyboard enabling, modal dialogs, grids with more than 100k lines without slowdown
I've test ExtJS and they not care about it (so deep as I need)

I just want to make them in pascal and keep the codebase and know-how I have in my team.

As I. I want (i;ve done succesfully) reuse 90% of desktop code in webbased. But you want to rewrite quite huge part to JS. Why? What for. Till now there is no example of any issue, that cant be done without translating pascal to JS without preserve all needs.

I agree. But I think that is new niche (cloud computing) and chance for me. This is quite new opportunities, many approaches , and we should know how choice proper.

I've still got to see the first install-less application. We have on average 1500 reports deployed with the application, several support DLLs of third-party tools and code, plus 6Mb. help files.

So why not create a link on the web site, where the users start, that downloads the program and runs it.

This is where the ship already sinks. I'll give you the 2 most common reasons:
- Many clients have PC-classrooms, where such things are simply forbidden.

- Windows Vista and security issues make installation and automated updates a pain. Not everybody is allowed to do installs, they don't have admin rights and whatnot.

I believe the only reason customers ask for browser-based RIA is that is the only choice they are familiar with because the media are all abuzz about it.

Nono. The IT people ask for it, because they want to be freed of the local installations. Worse: once parents of school pupils are involved, the problems increase thousandfold...

Other, better choices have been around for a long time that solve the same problem.

If you come and say this in front of my clients, I guarantee you that they will carry you out, covered in tar and feathers, and drop you in the nearest river :-)

I understand all your arguments, I have used them myself, but it is simply not my decision. So I try to save whatever is possible...

Michael.

I know, Morfik does all this.

Because some of the (rather complex) business logic must be in the client to make it respond as a desktop application.

A simplified example: 2 sets of data. 2 comboboxes. User chooses from set 1 in combobox 1. Based on his choice, the data in the second checkbox must be filtered. This must be done without round-trip to the server, because the data 2 set is large, and combobox 1 is used often. So I need some part of the business logic (complex relation between items in 2 sets of data) on the client.

As far as I'm concerned, Morfik is the correct approach. If I can do what they do in Lazarus and open source: I'm sold.

Michael.

Michael writes:

This is where the ship already sinks. I'll give you the 2 most common reasons:
- Many clients have PC-classrooms, where such things are simply forbidden.

- Windows Vista and security issues make installation and automated updates
a pain. Not everybody is allowed to do installs, they don't have admin rights and whatnot.

----

There is a bad virus going around certain parts of the UK in which the solution is to clamp down even more tightly in what limited things one can do with computers in schools which are very prone to viruses. A friend of mine over there who manages the IT of a certain school is constantly weighing new features vs security problems they may cause and I'm glad I don't have that job. Pretty soon they may just have to give up computers completely - a rash statement but the cost of doing total reinstalls for 100-500 computers is certainly not fun or productive. Maybe the solution is for all Pascal programmers to take an anti-virus oath - ;) At least you might not get tarred and feathered for making that statement - just a lot of blank stares. heh - ROW

Well, like other discussions, we could discuss all about this forever. We can't force our POV, no matter how good the arguments to support it, to other people. Every each of us has our own needs which can be fulfilled with any approaches we think best to us based on our condition and situation. What we think to be the best for us doesn't mean it would be the best for others. We may disagree with other people approaches, but that's all we can do: disagree.

As we provide solutions to pascal developers, IMO more alternatives would be better. Let our users choose any solutions that they think would be best for them. Whether to be all on server side or browser side is not our decision, it's theirs. I believe they realize the consequences of the decision they would take. So, let's provide more options and alternatives to them, and let them choose. ;)

Now, let's get back on to the topic of this thread. :)

I've been reading this thread for a while and wanted to ask something...

What if someone had a cluster based cloud computing server written entirely from the ground up in Delphi? Including hot-swappable core object for backend AJAX calls and all the major Web2.0 protocol implements (XMPP/HTTP/SMTP/POP3)...

Would there be anyone or a group of people reading this who would be willing to help port it from Delphi into a FPC/Lazarus xPlatform build?

Would there be anyone or a group of people reading this who know where one could procure funding for an open source Social Media Server?

If you are interested in contributing code or can help in any way please let me hear from you...

Thanks.

Michael Van Canneyt pisze:

I don't agree. Only one requirement should be fulfill, respond in reasonable time, say less than 500ms.
My way: only visible rows are send to browser, say 30 rows, they took about 3kb, time 3ms in LAN, 100ms when server is on second side of world. Rendering 100..300ms, on slow browser maybe longer. Even it it will be done after each of user action its no problem for server neither rest of infrastructure. On application side: its no matter that is desktop or web based, events and response are the same.

Your way: first transmit whole database to browser, JS compute what part should be display. When set of date is bigger you can send partial. But after select combobox all data must be send to compute filtering. On slight set it may work, but not on big.
But even on small sets of data time of response will be notable (I've seen ExtJS demo, its only on browser side, and its work rather slow, can you expect, that most of your code will have better optimization)

And what about transfer tons on JS to browser?

I cant found any site/application prepare by Morfik. Do you know any site, that I can see
Darek

500 ms is WAY too slow.

Nono. We're not talking about 30 rows, more like 5000-7000. Transmitted once, when the window is opened. That the window is slow to open initially is OK, but once opened it should work lightning fast for the duration of use.

I simplified it a bit, but it is a real life example.

I've seen it in action in Morfik, and it works fast.

And what about transfer tons on JS to browser?

Ah, morfik has a nice thing for this: you can preload forms asynchronously.

You can also download the chess example. (if it is still available)

Michael.

Adrian Veith pisze:

As i mention before 1..2 kLOC all JS code for whole application. But it doesn't matter. Most of them is universal, as LCL. Is small as assembler inlines in most of applications.

If you can't do everything on the server, you have to perform some part of the logic on the client.

Why any on logic move to client. I say only about GUI computation.

I have the same point. Strong language is best choice for huge application. I don't want to leave pascal, because it work: on desktop, on web side, without imaginable limitation (performance, portables, flexibility).
Second: I don't want depend from users computer, name and version browser, plugins. But if you move more code to client side, then more dependences you acquire.

And about HAXE. Its tool to write application for browser. For it seems good. But I told about moving desktop, client-server, multiuser application to web-based. Maybe HAXE in outline similar to FPC, but till now hundred times smaller. Who trust this young and unknown technology and base huge application on it. And server side ? You can translate client site to JS, server site to PHP, but what about communication client-server.

Darek

Andrew Brunner pisze:

Sound impressive. May i ask for more details.

Would there be anyone or a group of people reading this who would be willing to help port it from Delphi into a FPC/Lazarus xPlatform build?

Why not. Fell free to ask.

Andrew, do you have an example, or web page where we can read more about the project?

Leonardo M. Ramé

Sure. I'm really trying hard to get this project out the door. It's ODBC Database driven with connection pooling happening on the thread manager level. The sockets implementation is where all the packets are routed via their assigned protocol via a mapping technology I've implemented with the capacity to handle tens of thousands of simultaneous connections per node.

When I get home I'll send out screen shots of the Server Management System. I tried porting the ItemListView component myself using LCL's Scrollbox component but ran into problems with Gnome and scrolling the box. But moving forward I think a Console Application via AJAX would be better suited than building native flavors.

I don't know if I want to let the "cat out of the bag" sort to speak. Once I release the server out in the open there's not going back. This is more of a "feeler" message to see if there are motivated (or wealthy/influential) people out here - that are wanting to help delivering an affordable open sourced alternative.

I'll chime in, I did a haxe servlet server called hxServlet, it's available on libs.haxe.org. I'm thinking of doing something similar for fpc. First, hxServlet is like ruby on rails mongrel, indeed it uses the http header parser from mongrel, however it uses haXe's neko vm as the server, and it's use is behind a proxy for delivering dynamic content as it's not a full featured httpd.

Anyway, what I'm considering for fpc is wrapping jsapi, spidermonkey's API, and link it into a pascal binary, which could contain a web server for server side apps, and could just be a scripting language for desktop apps. My focus tends to be web apps.

I think with spidermonkey now able to JIT and a server side JS API movement taking shape, http://groups.google.com/group/serverjs, that server side Javascript backed by a pascal runtime is quite a nice combination. My goal would be to use RTTI to expose any pascal object as a js global without pain and be able to create a servlet e.g. (off the top of my head) ...

makeServlet(function(srv) {
srv.url ="/servlets/helloworld";
srv.doGet(function(headers)) {

   sqlite.query("select * from ...") ;
   print "hello world"
  })

})

It would be easy to decide which code should be written in JS and which to be moved to Pascal for speed or plumbing, in this example, sqlite a global JS object registered from fpc hopefully transparently. Maybe this has been done already - for another language? - if so great !.

Regards, targeted and compiled javascript on the client, like gwt or haxe (i did a haxe hxScriptlet similar to jquery), the problem is debugging it, and using existing libs, you can, but it's painful, and my takeaway from trying it, is it's not worth it, as you're fighting against the tide. If you give it some time JS is actually very nice, and with a tool like JSlint or a sophisticated editor like netbeans you can remove most of the pain points. I would think the inclusion of tooling for JS within lazarus, codetools for JS, would be a good (for me anyway :)) - so that development could be done naturally from one place.

I'm fairly new to fpc and and object pascal, but I've decided that I'm fed up with VMs, when I look at fpc I wonder where the huge advancements in VMs are apart from complexity and memory consumption - i do make a distinction with a VM in a scripting language, but for something I have to compile anyway i'm not convinced of the wins.

Thanks for fpc, it's very pleasant to work with.

Cheers

bd

Michael Van Canneyt pisze:

I've just test morfik issue tracker on http://m2.issuetracker.morfik.com, no one of response was faster than 500ms (by firebug), for many action browser need mode than one transmit to server and for many action, like last issue, find with zero results, filter by status time of compute new site was longer than 3 s And its only 195 records database.

30 rows are transmit to browser. In database I have 1M and more. I doubt that filtering from 5000 by JS will be faster than transmit 30 rows. But for 50000 im quite sure.

What about issue tracker. Its rather simple application, very small database and for me work slow.

Small resume about morfik:
it doesn't use CSS
it doesn't use cookie to identify session (with this browser don't cache images)
It just use HTML and JS, as most of web application it transfer each user action to server and wait for response (I say the same)
server response are quite big (simple login form need 11kb)

of course morfik looks good, then have very skill designer

you wrote

I'll chime in, I did a haxe servlet server called hxServlet, it's available on libs.haxe.org. I'm thinking of doing something similar for

....

Sorry for interrupt this thread, but returning to my first question and the next answers, i want to make a apache-tomcat like servlet server, open-source (BSD like license) and in free-pascal. No VMs, or bounded to one or few languages, only a servlet server that switch on the servlets, sends them the data and receives from them the data.

I want to make a cloud computing using servlets, it allows me to load-balance the load between different servers, use different architectures, different technologies, etc..

In some weeks i'll try to get something useful and share it.

Thanks a lot to everyone.

Eduardo

This is not correct, because it most certainly does. I hand-edited them suspect you simply didn't spot the references. A lot is done in Javascript :-)

it doesn't use cookie to identify session (with this browser don't cache images)

It does, but can do without.

It just use HTML and JS, as most of web application

Obviously, it's fully AJAX based.

it transfer each user action to server and wait for response (I say the same) server response are quite big (simple login form need 11kb)

This is demonstratibly uncorrect, because Morfik can create client-side only applications, in which no server app is needed: your whole application is encoded in Javascript, and sent to the browser. I have created several of those. They can use a 'database' which consists of a XML file on the server.

of course morfik looks good, then have very skill designer

I suggest you actually try it to make an application yourself. It's really good. Then you can discuss further, but in private, as we're getting very off-topic now.

(although Morfik uses FPC in the background to compile the server, so strictly speaking it's not so off-topic)

Michael.