Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2009-01

fpWeb - Apache Modules

20 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Lee Jenkins

I'm playing around with the fpWeb stuff and it looks really good. I may use it for some work on my company's website but I wanted to make sure that I could use either cgi or apache dso.

Are there any examples for apache shared modules or is it pretty much the same as the CGI? I see they both share the same ancestor datamodule descendant.

Are there any tutorials for setting up the apache mod version? I plan to most of the coding with the cgi but again, want to make sure that the apache module version would work as well.

Thanks,

Warm Regards, Lee

Reply by email

Lee Jenkins
to Lee Jenkins
Lee Jenkins wrote 11 lines
I'm playing around with the fpWeb stuff and it looks really good. I may use it for some work on my company's website but I wanted to make sure that I could use either cgi or apache dso. Are there any examples for apache shared modules or is it pretty much the same as the CGI? I see they both share the same ancestor datamodule descendant. Are there any tutorials for setting up the apache mod version? I plan to most of the coding with the cgi but again, want to make sure that the apache module version would work as well.

I've been tickering a bit and I need to ask if anyone is using the apache module version of fpWeb? I've tried for about an hour and half to get apache2 to run with a sample module to no avail.

Library mod_test;
{$mode objfpc}{$H+}
Uses
   fpWeb,lazweb,httpd,fpApache, web1;
Const

{ The following constant is used to export the module record. It must always match the name in the LoadModule statement in the apache configuration file(s). It is case sensitive !}

   ModuleName='test';

{ The following constant is used to determine whether the module will handle a request. It should match the name in the SetHandler statement in the apache configuration file(s). It is not case sensitive. }

   HandlerName=ModuleName;
Var
   DefaultModule : module;
{$ifdef unix} public name ModuleName;{$endif unix}
{$ifdef windows}
Exports defaultmodule name ModuleName;
{$endif windows}
{$IFDEF WINDOWS}{$R mod_test.rc}{$ENDIF}
begin
   Application.ModuleName:=ModuleName;
   Application.HandlerName:=HandlerName;
   Application.SetModuleRecord(DefaultModule);
   Application.Initialize;
end.

My Apache2 httpd.conf:

LoadModule test modules/mod_test.so
<Location /test>
SetHandler test-handler
</Location>

When trying to start apache, I get:
"Syntax error on line 136 of C:/Program Files/Apache Group/Apache2/conf/httpd.conf: Cannot load C:/Program Files/Apache Group/Apache2/modules/mod_test.so into server: The specified module could not be found."

The mod_test.so executable is definitely in the /modules directory of the Apache installation. Has anyone had this working or can provide a hint or two?

I'm on Lazarus 927 on Vista.

I'm a little frustrated at this point so I'm going to go for a walk... :)

Thanks,

Warm Regards, Lee

Reply by email

Lee Jenkins
to Lee Jenkins: I'm playing around with the fpWeb stuff and it looks really good. I may use it for some…
Lee Jenkins wrote 11 lines
I'm playing around with the fpWeb stuff and it looks really good. I may use it for some work on my company's website but I wanted to make sure that I could use either cgi or apache dso. Are there any examples for apache shared modules or is it pretty much the same as the CGI? I see they both share the same ancestor datamodule descendant. Are there any tutorials for setting up the apache mod version? I plan to most of the coding with the cgi but again, want to make sure that the apache module version would work as well.

After working quite a few hours to get this to work yesterday, I have found the solution:

Start > All Programs > Microsoft Visual Studio 2008

Warm Regards, Lee

Reply by email

Andrew Brunner
to Lee Jenkins
Lee Jenkins wrote 8 lines
After working quite a few hours to get this to work yesterday, I have found the solution: Start > All Programs > Microsoft Visual Studio 2008 -- Warm Regards,

Lee, with the hope of not going too far off topic... I'm running Ubuntu 8.10 for tripple core AMD x64 machine. I'm looking for a "start" option... "all programs" etc. I only have an Applications menu item. :-)

And what in the world is "Microsoft Visual Studio 2008"? A lazarus plugin?

LOL. But seriously, good luck getting anything you write to work on a Linux box without FPC/Lazaurs. Microsoft is rapidly becoming irrelevant compared to Linux.

Reply by email

Lee Jenkins
to Andrew Brunner
Andrew Brunner wrote 15 lines
On Thu, Jan 22, 2009 at 7:20 AM, Lee Jenkins wrote: > After working quite a few hours to get this to work yesterday, I have found the > solution: > > Start > All Programs > Microsoft Visual Studio 2008 > > -- > Warm Regards, > Lee, with the hope of not going too far off topic... I'm running Ubuntu 8.10 for tripple core AMD x64 machine. I'm looking for a "start" option... "all programs" etc. I only have an Applications menu item. :-)

I do not have it on my CentOS installation either. ;)

LOL. But seriously, good luck getting anything you write to work on a Linux box without FPC/Lazaurs. Microsoft is rapidly becoming irrelevant compared to Linux.

Well, I know that some people are having good success with Asp.net/mono. But I would definitely prefer to use Lazarus/FPC. I don't prefer C# and certainly not vb.net. The problem is that there is no working solution for web work available for Lazarus/FPC that meets my needs.

1. It works.

2. I should not have to divert an appreciable amount of my life to learning how to use the technology or getting it to work.

3. Must support database connection/object pooling.

Powtils and other only cgi frameworks by their nature do not support object pooling. The only other option that I saw was apache dso's using the fpWeb framework but that did not turn out too well and I spent quite a long time trying to get apache to load the dso (which it would not) let alone actually running it.

Also, please don't misunderstand me, I like lazarus/fpc and I have a strong appreciation for the work that its contributors do. I would be happy to look at any other solutions for lazarus/fpc that I have not found that meet the above criteria.

Warm Regards, Lee

Reply by email

ABorka
to Lee Jenkins: I've been tickering a bit and I need to ask if anyone is using the apache module version…

Yes, apache modules are working.

However, most of the example programs are obsolete and not working without some changes.

You also have to be sure to use the right FCL directory for your Apache version (httpd13, httpd20, httpd22).

Lee Jenkins wrote 85 lines
Lee Jenkins wrote: > I'm playing around with the fpWeb stuff and it looks really good. I may use it > for some work on my company's website but I wanted to make sure that I could use > either cgi or apache dso. > > Are there any examples for apache shared modules or is it pretty much the same > as the CGI? I see they both share the same ancestor datamodule descendant. > > Are there any tutorials for setting up the apache mod version? I plan to most > of the coding with the cgi but again, want to make sure that the apache module > version would work as well. > I've been tickering a bit and I need to ask if anyone is using the apache module version of fpWeb? I've tried for about an hour and half to get apache2 to run with a sample module to no avail. Library mod_test; {$mode objfpc}{$H+} Uses fpWeb,lazweb,httpd,fpApache, web1; Const { The following constant is used to export the module record. It must always match the name in the LoadModule statement in the apache configuration file(s). It is case sensitive !} ModuleName='test'; { The following constant is used to determine whether the module will handle a request. It should match the name in the SetHandler statement in the apache configuration file(s). It is not case sensitive. } HandlerName=ModuleName; Var DefaultModule : module; {$ifdef unix} public name ModuleName;{$endif unix} {$ifdef windows} Exports defaultmodule name ModuleName; {$endif windows} {$IFDEF WINDOWS}{$R mod_test.rc}{$ENDIF} begin Application.ModuleName:=ModuleName; Application.HandlerName:=HandlerName; Application.SetModuleRecord(DefaultModule); Application.Initialize; end. My Apache2 httpd.conf: LoadModule test modules/mod_test.so <Location /test> SetHandler test-handler </Location> When trying to start apache, I get: "Syntax error on line 136 of C:/Program Files/Apache Group/Apache2/conf/httpd.conf: Cannot load C:/Program Files/Apache Group/Apache2/modules/mod_test.so into server: The specified module could not be found." The mod_test.so executable is definitely in the /modules directory of the Apache installation. Has anyone had this working or can provide a hint or two? I'm on Lazarus 927 on Vista. I'm a little frustrated at this point so I'm going to go for a walk... :) Thanks, -- Warm Regards, Lee _______________________________________________ Lazarus mailing list http://www.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply by email

Lee Jenkins
to ABorka
ABorka wrote
Yes, apache modules are working. However, most of the example programs are obsolete and not working without some changes.

I would say that effectively makes it unusable unless one is willing to guess their way through.

You also have to be sure to use the right FCL directory for your Apache version (httpd13, httpd20, httpd22).

I was hoping to be able to use the Lazarus's "New Project" template through fpWeb that has itself a Apache DataModule. Does this not work then? Because this is what I've been using.

If you're referring to the example on the wiki, that looks a lot like spaghetti code to me and very non-object pascal looking. No offense to whomever wrote it, of course. That kind of code should probably be abstracted out to objects like the apache module new project template.

Warm Regards, Lee

Reply by email

ABorka
to Lee Jenkins

Lazarus file/new should work, just make sure to use the right httpdXX directory.

http://bugs.freepascal.org/view.php?id=12375
is not included in the source yet, so you might want to add it yourself

Lee Jenkins wrote 31 lines
ABorka wrote: > Yes, apache modules are working. > > However, most of the example programs are obsolete and not working > without some changes. I would say that effectively makes it unusable unless one is willing to guess their way through. > You also have to be sure to use the right FCL directory for your Apache > version (httpd13, httpd20, httpd22). > I was hoping to be able to use the Lazarus's "New Project" template through fpWeb that has itself a Apache DataModule. Does this not work then? Because this is what I've been using. If you're referring to the example on the wiki, that looks a lot like spaghetti code to me and very non-object pascal looking. No offense to whomever wrote it, of course. That kind of code should probably be abstracted out to objects like the apache module new project template. -- Warm Regards, Lee _______________________________________________ Lazarus mailing list http://www.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply by email

Lee Jenkins
to ABorka
ABorka wrote
Lazarus file/new should work, just make sure to use the right httpdXX directory.

Thanks, but how do I tell Lazarus which one to use? I assumed that if it was on the path, anyone of them could be used. For instance if I setup a new apache module project and hover over "httpd" in the uses clause, it shows me that its pulling in the 1.3 version instead of the 2.0 version which I need.

http://bugs.freepascal.org/view.php?id=12375 is not included in the source yet, so you might want to add it yourself

Is there a facility in Lazarus that will apply a patch like that? I've only ever used patches with source that I originally svn'ed.

Thanks again,

Warm Regards, Lee

Reply by email

Graeme Geldenhuys
to Lee Jenkins: I do not have it on my CentOS installation either. ;) Well, I know that some people are…
Lee Jenkins wrote 5 lines
Powtils and other only cgi frameworks by their nature do not support object pooling. The only other option that I saw was apache dso's using the fpWeb framework but that did not turn out too well and I spent quite a long time trying to get apache to load the dso (which it would not) let alone actually running it.

I have currently written a large chunk of our application using Powtils for standard CGI applications. I miss object pooling or DB connection pooling a lot. Setting up a connection is very slow compared to many other things, and having to do that on every mouse click is not ideas.

I will be investigating alternative options. fpWeb and DSO etc.. I even thought of creating a Application Server application like in a 3-tier app. The CGI apps then communicate to the application server. The app server is the only one that has the actual DB connection. In theory this will work, but I haven't tried a prototype yet.

Also, Michael van Canneyt has written some articles on Free Pascal/Lazarus and web apps. Maybe if you ask nicely, he can send you those, which might give some hints on how to use fpWeb etc.. :-)

Regards,
- Graeme -

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

Reply by email

Henry Vermaak
to Graeme Geldenhuys

2009/1/23 Graeme Geldenhuys :

Show quoted text 12 lines
On Thu, Jan 22, 2009 at 4:51 PM, Lee Jenkins wrote: > Powtils and other only cgi frameworks by their nature do not support object > pooling. The only other option that I saw was apache dso's using the fpWeb > framework but that did not turn out too well and I spent quite a long time > trying to get apache to load the dso (which it would not) let alone actually > running it. I have currently written a large chunk of our application using Powtils for standard CGI applications. I miss object pooling or DB connection pooling a lot. Setting up a connection is very slow compared to many other things, and having to do that on every mouse click is not ideas.

just for interest sake, have you measured how long it takes to set up the connection relative to how long the network transfer takes? it'll obviously be dependant on the connection speed, but i get the feeling that it's minimal.

henry

Reply by email

Graeme Geldenhuys
to Henry Vermaak
Henry Vermaak wrote 5 lines
just for interest sake, have you measured how long it takes to set up the connection relative to how long the network transfer takes? it'll obviously be dependant on the connection speed, but i get the feeling that it's minimal.

Yes I have, and so did other users of tiOPF. The Connect/Disconnect part of a database takes considerably longer than retrieving a subset of data. And with the way CGI applications work, they connect/disconnect very often (each screen refresh).

I say "subset of data" because I only retrieve what I need. I NEVER do a "select * from <tablename>".

Regards,
- Graeme -

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

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys
Graeme Geldenhuys wrote 11 lines
On Fri, Jan 23, 2009 at 11:43 AM, Henry Vermaak wrote: > > just for interest sake, have you measured how long it takes to set up > the connection relative to how long the network transfer takes? it'll > obviously be dependant on the connection speed, but i get the feeling > that it's minimal. Yes I have, and so did other users of tiOPF. The Connect/Disconnect part of a database takes considerably longer than retrieving a subset of data. And with the way CGI applications work, they connect/disconnect very often (each screen refresh).

All depends on how your CGI application works.
For any reasonably user-friendly application screen buildup usually requires so many queries that the startup time is dwarfed.

Take the mantis bugtracker: it runs more than 40 queries to show certain pages ('My view' page takes 45) , and needs sometimes up to 100 Mb (!!) to display a single page. I had to increase the allowed memory per page in php.ini to be able to run Mantis.

In such cases, reverting to CGI will IMHO result in a speed gain. PHP has become so bloated that it slows with every release.

For simple CGI's a lot can be improved by caching some things in the session data, which you of course should not store in the database. If you need to run a query on the database to display the user name in the top-right corner of your web-page, your design is basically flawed.

Not to mention that CGI (or apache modules) are less prone to attacks than the ubiquitous interpreted PHP...

Michael.

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt
Michael Van Canneyt wrote
All depends on how your CGI application works. For any reasonably user-friendly application screen buildup usually requires so many queries that the startup time is dwarfed.

[....]

For simple CGI's a lot can be improved by caching some things in the session data, which you of course should not store in the database.

Correct. I should have mentioned that we do cache some information to speed up page building and limit the amount of queries.

Regards,
- Graeme -

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

Reply by email

Henry Vermaak
to Graeme Geldenhuys: Yes I have, and so did other users of tiOPF. The Connect/Disconnect part of a database…

2009/1/23 Graeme Geldenhuys :

Show quoted text 10 lines
On Fri, Jan 23, 2009 at 11:43 AM, Henry Vermaak wrote: > > just for interest sake, have you measured how long it takes to set up > the connection relative to how long the network transfer takes? it'll > obviously be dependant on the connection speed, but i get the feeling > that it's minimal. Yes I have, and so did other users of tiOPF. The Connect/Disconnect part of a database takes considerably longer than retrieving a subset of data. And with the way CGI applications work, they

of course, but i mean the internet transfer of the html to the client's browser.

henry

Reply by email

Graeme Geldenhuys
to Henry Vermaak
Henry Vermaak wrote
of course, but i mean the internet transfer of the html to the client's browser.

That I have not tested yet, but not much I can do about that either. We do limit the amount of content in the generated pages. Example: only include the JavaScript functions required for the set task/page, remove debug HTML comments in the released version etc... every byte helps. :-)

Our product currently only runs over a LAN, not a WAN. But the latter is something we will be considering in the future. Our CGI apps stream a LOT of flash content, because that's the bulk of our product (teaching mathematics).

The other connections slow down is dependent on how busy the server hosting the RDBMS is. We have found that if the server is heavily stressed, the connection times increase a lot. This is where I hope our 3-tier prototype will help. Where the app server has a connection pool - one less thing for the CGI app to do.

Regards,
- Graeme -

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

Reply by email

Lee Jenkins
to Graeme Geldenhuys: I have currently written a large chunk of our application using Powtils for standard CGI…
Graeme Geldenhuys wrote 12 lines
On Thu, Jan 22, 2009 at 4:51 PM, Lee Jenkins wrote: > Powtils and other only cgi frameworks by their nature do not support object > pooling. The only other option that I saw was apache dso's using the fpWeb > framework but that did not turn out too well and I spent quite a long time > trying to get apache to load the dso (which it would not) let alone actually > running it. I have currently written a large chunk of our application using Powtils for standard CGI applications. I miss object pooling or DB connection pooling a lot. Setting up a connection is very slow compared to many other things, and having to do that on every mouse click is not ideas.

Right. Since CGI is a one-off technology, you have to setup and tear down db connections, which (and I could be wrong here) tiOPF takes a bit longer to do than standard TConnect > TDataset model and since I use tiOPF as well, I'd prefer not to take a hit like that if I don't have to.

Show quoted text 5 lines
I will be investigating alternative options. fpWeb and DSO etc.. I even thought of creating a Application Server application like in a 3-tier app. The CGI apps then communicate to the application server. The app server is the only one that has the actual DB connection. In theory this will work, but I haven't tried a prototype yet.

One idea that I had was to use a gateway application, much like they're doing uses FastCGI in one of 2 ways.

1. Gateway App => FastCGI Server. This model is designed for webservers that don't have cgi support. A standard gateway.cgi application takes the actual rqeuest and then communicates with a backend FastCGI (basically TCP/IP) server to fill the request.

2. Stand alone FastCGI server. This is the FastCGI server used in the first model but is used for web servers that have native FastCGI support. In this model the server (apache) just talks to the persistent running FastCGI server directly.

There server is pretty well abstracted out of the ExtJS stuff that the project is based on so I may just use their code for ideas.

Of course, FastCGI (like apache DSO's) have their drawbacks in terms of being able to actually use them on a shared hosting plan as most providers do not allow you to install DSO's or long running processes like TCP/FastCGI servers.

But a nice compromise would be to write a cgi gateway like in ExtPascal with a few minor changes so that my business logic can be the same regardless of whether its standard cgi running on a low traffic Plesk/CPanel account or a dedicated server.

Also, Michael van Canneyt has written some articles on Free Pascal/Lazarus and web apps. Maybe if you ask nicely, he can send you those, which might give some hints on how to use fpWeb etc.. :-)

Michael? Michael? Where art thou and whilst thou share thine most valuable knowledge with me? :)

Warm Regards, Lee

Reply by email

Lee Jenkins
to Graeme Geldenhuys: Yes I have, and so did other users of tiOPF. The Connect/Disconnect part of a database…
Graeme Geldenhuys wrote 10 lines
On Fri, Jan 23, 2009 at 11:43 AM, Henry Vermaak wrote: > just for interest sake, have you measured how long it takes to set up > the connection relative to how long the network transfer takes? it'll > obviously be dependant on the connection speed, but i get the feeling > that it's minimal. Yes I have, and so did other users of tiOPF. The Connect/Disconnect part of a database takes considerably longer than retrieving a subset of data. And with the way CGI applications work, they connect/disconnect very often (each screen refresh).

Yeah, this is a problem for us tiOPF users since the tiOPF not only needs to setup its database specific objects like pooling, etc but also has to perform all of the object registrations if you're using AutoMapping a lot like I do.

Warm Regards, Lee

Reply by email

Graeme Geldenhuys
to Lee Jenkins
Lee Jenkins wrote
Yeah, this is a problem for us tiOPF users since the tiOPF not only needs to setup its database specific objects like pooling, etc but also has to perform all of the object registrations if you're using AutoMapping a lot like I do.

I don't use AutoMapping, so I can't comment on it's speed. But for "hard coded visitors", I have not noticed any slowdown because we use tiOPF. After all, tiOPF uses the same components you would have dropped on a TDataModule.

Regards,
- Graeme -

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

Reply by email

Lee Jenkins
to Graeme Geldenhuys
Graeme Geldenhuys wrote 10 lines
On Fri, Jan 23, 2009 at 5:40 PM, Lee Jenkins wrote: > Yeah, this is a problem for us tiOPF users since the tiOPF not only needs to > setup its database specific objects like pooling, etc but also has to perform > all of the object registrations if you're using AutoMapping a lot like I do. I don't use AutoMapping, so I can't comment on it's speed. But for "hard coded visitors", I have not noticed any slowdown because we use tiOPF. After all, tiOPF uses the same components you would have dropped on a TDataModule.

I wasn't referring to the execution speed. For that, tiOPF is as fast as any. I was talking about the initial load of the program where its customary to put the registration of your automap mappings in the inititialization section of your units. It's just one more thing to load before your program executes which is not really a problem now, but could potentially add to the responsive of the CGI if there are many business objects being registered at program startup.

Warm Regards, Lee

Reply by email