Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Sun, 4 Nov 2007, Joost van der Sluis wrote: Op zondag 04-11-2007 om 00:34 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Joost van der Sluis wrote: Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt: Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset? I need all features offered by TClientDataset: - 3-tier database handling, TProvider and all. - Local filtering - Local sorting/indexing - Locate() - Maintained Aggregates - Load/Save to file (briefcase model) And all features are critical; We have about 3200 instances in 1 application, almost all of them using all of the features mentioned, maybe with exception of the aggregates. Or do you only miss some features in sqldb? SQLDB will be good for our server tier, so I can drop the IBX. But it's not suitable for the client layer. As I see it, TClientDataset should be built on top of TBufDataset. Local filtering is available as fas as I know (or did you put it in TSQLQuery ?), and the indexing probably also can somehow be managed. The locate can be done with a filter. The maintained aggregates would need to be implemented from scratch, as well as the packet handling and file handling... Local filtering is in TBufDataset, locate also. The packet-handling is also there? So you can create a delta packet, it can be sent/applied/whatever, and you can integrate whatever changes were incorporated after the delta was applied ? I must have missed that ? Only no file-handling. But that's more because I didn't find it urgent enough to implement. It should be very easy. And there are no local indexes. The local indexes are one of THE most important things. The file handling is relatively easy, but should be designed well so it can handle various formats. Bu I know where to work on now. But there's also a design-issue. You talked about a TProvider. But as TBufdataset is setup know, you don't need any. For every kind of connection between TBufDataset and the ouside world, you'll have to use another descendent of TBufDataset. TProvider is needed to 1. Supply initial data. 2. Apply the deltas and send back reconciling data. So we can add a TProviderDataset or something, that can connect to data on an application-server. Is this ok to you? That way you always heve to re-create your descendent of TBufDataset for every connection? Hm. I'm not sure I understand this ? Or do you like the TClientDataset model better? So that you can connect it to any TProvider you want - to get access to some data? This is essential; Without this it is useless to me. You're right that we could make a TClientDataset which inherits from TBufDataset. But that kind of defeats the purpose of TBufDataset. Nono. You should split out functionalities: The TBufDataset should handle what it handles now, plus the local indexes and saving to file. In short: a complete in-memory dataset. It doesn't care where the actual data comes from; This is the job of a descendent. (TSQLQuery, TClientDataset) What TClientDataset adds to this is the ability to work with a TProvider: - Get records from a remote source (IAppProvider interface). - Send and Apply delta, integrate result back in buffer. Because if you do so, it would also be better to base TSQLQuery on TDataset directly. Or else you're double-buffering your data when you connect a TSQLQuery (TBufDataset) with a TProvider to a TClientDataset (another TBufDataset). You'll always have double buffering. Don't forget that TSQLQuery and TProvider are on the application server tier, and TClientDataset is on the client tier. The client tier doesn't have direct access to the database so TSQLQuery would be useless. That's why a 'unidirectional' property in TSQLQuery/TBufDataset is needed: in that case, only 2 buffers are needed: one for the current record and one for edit/update/filter. Makes a HUGE difference on the server. IBX implemented it especially for that. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Look, I don't try to convince you that Lazarus or FPC should make extensive use of packages - we worked years without it and we worked very well, If using packages is the way to go to make installing visual components in Lazarus, IMHO it's essential to use them there ASAP. It would be really nice to have a predefined way to do/deploy plugins (that should not depend on compiler versions and maybe should be doable in C, too). Maybe something supporting those could be worth some thoughts, too. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
Op maandag 05-11-2007 om 10:44 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sun, 4 Nov 2007, Joost van der Sluis wrote: Op zondag 04-11-2007 om 00:34 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Joost van der Sluis wrote: Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt: Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset? I need all features offered by TClientDataset: - 3-tier database handling, TProvider and all. - Local filtering - Local sorting/indexing - Locate() - Maintained Aggregates - Load/Save to file (briefcase model) And all features are critical; We have about 3200 instances in 1 application, almost all of them using all of the features mentioned, maybe with exception of the aggregates. Or do you only miss some features in sqldb? SQLDB will be good for our server tier, so I can drop the IBX. But it's not suitable for the client layer. As I see it, TClientDataset should be built on top of TBufDataset. Local filtering is available as fas as I know (or did you put it in TSQLQuery ?), and the indexing probably also can somehow be managed. The locate can be done with a filter. The maintained aggregates would need to be implemented from scratch, as well as the packet handling and file handling... Local filtering is in TBufDataset, locate also. The packet-handling is also there? So you can create a delta packet, it can be sent/applied/whatever, and you can integrate whatever changes were incorporated after the delta was applied ? I must have missed that ? Yes. But you can only apply the 'delta-packet'. Or cancel it, offcourse (ie: remove it). But that's because saving to disk and sending to another TDataser or over the network isn't implemented at all. Only no file-handling. But that's more because I didn't find it urgent enough to implement. It should be very easy. And there are no local indexes. The local indexes are one of THE most important things. The file handling is relatively easy, but should be designed well so it can handle various formats. Bu I know where to work on now. But there's also a design-issue. You talked about a TProvider. But as TBufdataset is setup know, you don't need any. For every kind of connection between TBufDataset and the ouside world, you'll have to use another descendent of TBufDataset. TProvider is needed to 1. Supply initial data. 2. Apply the deltas and send back reconciling data. You don't need a TProvider for that. Take for example sqldb: TSQLQuery does nothing more (or less) then a TProvider would do. TBufDataset does the rest. (btw: TSQLQuert doesn't send back reconciling data, although TBufdataset can handle it) So we can add a TProviderDataset or something, that can connect to data on an application-server. Is this ok to you? That way you always heve to re-create your descendent of TBufDataset for every connection? Hm. I'm not sure I understand this ? Read the example above. See TSQLCustomQuery as the provider, TBufDataset as the TClientDataset. Or do you like the TClientDataset model better? So that you can connect it to any TProvider you want - to get access to some data? This is essential; Without this it is useless to me. I need to know if you can also use the model above. You're right that we could make a TClientDataset which inherits from TBufDataset. But that kind of defeats the purpose of TBufDataset. Nono. You should split out functionalities: The TBufDataset should handle what it handles now, plus the local indexes and saving to file. In short: a complete in-memory dataset. It doesn't care where the actual data comes from; This is the job of a descendent. (TSQLQuery, TClientDataset) What TClientDataset adds to this is the ability to work with a TProvider: - Get records from a remote source (IAppProvider interface). - Send and Apply delta, integrate result back in buffer. TBufDataset can already do this. A descendent has to: Override Fetch, LoadField, LoadBlobintoBuffer and ApplyrecUpdate. (integrating the results in the buffer is done by TBufDataset, just as TClientDataset does) So TClientDataset could override these functions simply in such a way that they call the same functions, but then form an external provider. ie: function TClientDataset.Fetch : boolean; begin Result := AProvider.Fetch; end; And all the like... If you really need compatibility with the IAppProvider interface (why?) then there's more work to do. But that was what I meant with my first question. Do you
Re: [fpc-devel] Dnamic packages support
On Mon, 05 Nov 2007 12:08:31 +0100 Michael Schnell [EMAIL PROTECTED] wrote: Look, I don't try to convince you that Lazarus or FPC should make extensive use of packages - we worked years without it and we worked very well, If using packages is the way to go to make installing visual components in Lazarus, IMHO it's essential to use them there ASAP. It would be really nice to have a predefined way to do/deploy plugins (that should not depend on compiler versions and maybe should be doable in C, too). Maybe something supporting those could be worth some thoughts, too. If you really want to write C plugin, then I can add a unit to the IDEIntf with some common functions without OOP. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Mon, 5 Nov 2007, Joost van der Sluis wrote: Op maandag 05-11-2007 om 10:44 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sun, 4 Nov 2007, Joost van der Sluis wrote: Op zondag 04-11-2007 om 00:34 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Joost van der Sluis wrote: Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt: Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset? I need all features offered by TClientDataset: - 3-tier database handling, TProvider and all. - Local filtering - Local sorting/indexing - Locate() - Maintained Aggregates - Load/Save to file (briefcase model) And all features are critical; We have about 3200 instances in 1 application, almost all of them using all of the features mentioned, maybe with exception of the aggregates. Or do you only miss some features in sqldb? SQLDB will be good for our server tier, so I can drop the IBX. But it's not suitable for the client layer. As I see it, TClientDataset should be built on top of TBufDataset. Local filtering is available as fas as I know (or did you put it in TSQLQuery ?), and the indexing probably also can somehow be managed. The locate can be done with a filter. The maintained aggregates would need to be implemented from scratch, as well as the packet handling and file handling... Local filtering is in TBufDataset, locate also. The packet-handling is also there? So you can create a delta packet, it can be sent/applied/whatever, and you can integrate whatever changes were incorporated after the delta was applied ? I must have missed that ? Yes. But you can only apply the 'delta-packet'. Or cancel it, offcourse (ie: remove it). But that's because saving to disk and sending to another TDataser or over the network isn't implemented at all. Aha. So we're partly there. TProvider is needed to 1. Supply initial data. 2. Apply the deltas and send back reconciling data. You don't need a TProvider for that. Take for example sqldb: TSQLQuery does nothing more (or less) then a TProvider would do. TBufDataset does the rest. (btw: TSQLQuert doesn't send back reconciling data, although TBufdataset can handle it) I understand all this, but the idea of TProvider is that the source of the data is opaque to the TClientDataset. So we can add a TProviderDataset or something, that can connect to data on an application-server. Is this ok to you? That way you always heve to re-create your descendent of TBufDataset for every connection? Hm. I'm not sure I understand this ? Read the example above. See TSQLCustomQuery as the provider, TBufDataset as the TClientDataset. Or do you like the TClientDataset model better? So that you can connect it to any TProvider you want - to get access to some data? This is essential; Without this it is useless to me. I need to know if you can also use the model above. If I understand your proposal correct, the answer is no. Which doesn't mean your proposal has no worth by itself, I think it does. You're right that we could make a TClientDataset which inherits from TBufDataset. But that kind of defeats the purpose of TBufDataset. Nono. You should split out functionalities: The TBufDataset should handle what it handles now, plus the local indexes and saving to file. In short: a complete in-memory dataset. It doesn't care where the actual data comes from; This is the job of a descendent. (TSQLQuery, TClientDataset) What TClientDataset adds to this is the ability to work with a TProvider: - Get records from a remote source (IAppProvider interface). - Send and Apply delta, integrate result back in buffer. TBufDataset can already do this. A descendent has to: Override Fetch, LoadField, LoadBlobintoBuffer and ApplyrecUpdate. (integrating the results in the buffer is done by TBufDataset, just as TClientDataset does) So TClientDataset could override these functions simply in such a way that they call the same functions, but then form an external provider. ie: function TClientDataset.Fetch : boolean; begin Result := AProvider.Fetch; end; And all the like... If you really need compatibility with the IAppProvider interface (why?) Why ? Because we make use of it in 3200 places, and recoding this is not an option :-) then there's more work to do. But that was what I meant with my first question. Do you need the functionality ot TClientDataset, or a symantical equivalent? I
Re: [fpc-devel] Dnamic packages support
If you really want to write C plugin, then I can add a unit to the IDEIntf with some common functions without OOP. I don't intend to doing that right now. But one of the most commonly used and supposedly complex and well defined plugin systems open to 3rd party providers is Steinberg (Cubase) plugins for MIDI/Audio applets. - the plugin API defines MIDI I/O, Audio I/O, GUI and supposedly some more weird stuff like copy protection dongles - there are working hosts and plugins for Windows, Linux and Mac - there are hundreds of companies providing those plugins (many freeware products) - there are hosts by several companies. Besides Steinberg products there is NI Core and even a hardware system (that runs on Linux) - I read about projects writing those plugins successfully with free Pascal So this _is_ a good example of an OS and language independent plugin API. Maybe it's a good idea to provide something compatible. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
From: Michael Van Canneyt [EMAIL PROTECTED] We could try to compile Borlands' VCL code with FPC, of course, but then there is the problem that the midas library is a black box, available only for windows i386, which kind of defeats the purpose of the whole exercise.. There is open source midas.dll implementation called HyperBase. http://www.vglib.com/link-4.html It can be made compilable by FPC to different platforms... Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Mon, 5 Nov 2007, Yury Sidorov wrote: From: Michael Van Canneyt [EMAIL PROTECTED] We could try to compile Borlands' VCL code with FPC, of course, but then there is the problem that the midas library is a black box, available only for windows i386, which kind of defeats the purpose of the whole exercise.. There is open source midas.dll implementation called HyperBase. http://www.vglib.com/link-4.html It can be made compilable by FPC to different platforms... Yes, I have it since a very long time :-) But it contains bugs :/ But if there is no alternative then that would be an option. Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
Op maandag 05-11-2007 om 12:37 uur [tijdzone +0100], schreef Michael Van Canneyt: On Mon, 5 Nov 2007, Joost van der Sluis wrote: Op maandag 05-11-2007 om 10:44 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sun, 4 Nov 2007, Joost van der Sluis wrote: Op zondag 04-11-2007 om 00:34 uur [tijdzone +0100], schreef Michael Van Canneyt: On Sat, 3 Nov 2007, Joost van der Sluis wrote: Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt: Packages and the missing TClientDataset are the only 2 remaining things stopping me from using FPC/Lazarus for my daytime job. All else is covered or can be covered with a minimal amount of work. You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset? I need all features offered by TClientDataset: - 3-tier database handling, TProvider and all. - Local filtering - Local sorting/indexing - Locate() - Maintained Aggregates - Load/Save to file (briefcase model) And all features are critical; We have about 3200 instances in 1 application, almost all of them using all of the features mentioned, maybe with exception of the aggregates. Or do you only miss some features in sqldb? SQLDB will be good for our server tier, so I can drop the IBX. But it's not suitable for the client layer. As I see it, TClientDataset should be built on top of TBufDataset. Local filtering is available as fas as I know (or did you put it in TSQLQuery ?), and the indexing probably also can somehow be managed. The locate can be done with a filter. The maintained aggregates would need to be implemented from scratch, as well as the packet handling and file handling... Local filtering is in TBufDataset, locate also. The packet-handling is also there? So you can create a delta packet, it can be sent/applied/whatever, and you can integrate whatever changes were incorporated after the delta was applied ? I must have missed that ? Yes. But you can only apply the 'delta-packet'. Or cancel it, offcourse (ie: remove it). But that's because saving to disk and sending to another TDataser or over the network isn't implemented at all. Aha. So we're partly there. TProvider is needed to 1. Supply initial data. 2. Apply the deltas and send back reconciling data. You don't need a TProvider for that. Take for example sqldb: TSQLQuery does nothing more (or less) then a TProvider would do. TBufDataset does the rest. (btw: TSQLQuert doesn't send back reconciling data, although TBufdataset can handle it) I understand all this, but the idea of TProvider is that the source of the data is opaque to the TClientDataset. So we can add a TProviderDataset or something, that can connect to data on an application-server. Is this ok to you? That way you always heve to re-create your descendent of TBufDataset for every connection? Hm. I'm not sure I understand this ? Read the example above. See TSQLCustomQuery as the provider, TBufDataset as the TClientDataset. Or do you like the TClientDataset model better? So that you can connect it to any TProvider you want - to get access to some data? This is essential; Without this it is useless to me. I need to know if you can also use the model above. If I understand your proposal correct, the answer is no. Which doesn't mean your proposal has no worth by itself, I think it does. You're right that we could make a TClientDataset which inherits from TBufDataset. But that kind of defeats the purpose of TBufDataset. Nono. You should split out functionalities: The TBufDataset should handle what it handles now, plus the local indexes and saving to file. In short: a complete in-memory dataset. It doesn't care where the actual data comes from; This is the job of a descendent. (TSQLQuery, TClientDataset) What TClientDataset adds to this is the ability to work with a TProvider: - Get records from a remote source (IAppProvider interface). - Send and Apply delta, integrate result back in buffer. TBufDataset can already do this. A descendent has to: Override Fetch, LoadField, LoadBlobintoBuffer and ApplyrecUpdate. (integrating the results in the buffer is done by TBufDataset, just as TClientDataset does) So TClientDataset could override these functions simply in such a way that they call the same functions, but then form an external provider. ie: function TClientDataset.Fetch : boolean; begin Result := AProvider.Fetch; end; And all the like... If you really need compatibility with the IAppProvider interface (why?) Why ? Because we
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Mon, 5 Nov 2007, Joost van der Sluis wrote: Why ? Because we make use of it in 3200 places, and recoding this is not an option :-) Ok, then there's the question: Do we want to provide the ability to use existing DB-code with fpc? It's a serious question, because if decide to do so, that will cost resources which could be otherwise used for something else. (Implementing a better db-model? Is the Delphi-model perfect?) I think that the DB model of Delphi is very OK, but can use some extensions. for instance TBufDataset can have a property Records[I : Integer] which could give direct indexed access to all records in the dataset (as, I understood, .NET does). This need not conflict with the current implementation. What concerns the possibilities of N-Tier, I have the same opinion. The ideas of Borland are OK, but the implementation can use some improvements. DataAbstract of Remobjects springs to mind. (although that one as well can use some improvements...) If I would start from zero, I would not have problems with setting up the whole thing to something like you describe. The main problem is that there is almost 10 years of code which should work as-is, as much as possible. Since we heavily rely on almost all aspects of TClientDataset/TProvider stuff, that means we need it almost 100% equivalently... We could try to compile Borlands' VCL code with FPC, of course, but then there is the problem that the midas library is a black box, available only for windows i386, which kind of defeats the purpose of the whole exercise.. I think I understand your point of view now. At first I thought that TBufDataset wouldn't be needed if we make a TClientDataset. But if you want to use a property to switch unidirectional on and off, it makes sense. Great, understanding is already half the path :-) What concerns the exact details of implementation, well, there we'll have to see. I can live with a small change in API (getting rid of variants, for one), as long as the global mechanism and idea is there. Maybe we should get together once, and sit around the drawing board... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
If you really want to write C plugin, then I can add a unit to the IDEIntf with some common functions without OOP. I don't intend to doing that right now. But one of the most commonly used and supposedly complex and well defined plugin systems open to 3rd party providers is Steinberg (Cubase) plugins for MIDI/Audio applets. - the plugin API defines MIDI I/O, Audio I/O, GUI and supposedly some more weird stuff like copy protection dongles - there are working hosts and plugins for Windows, Linux and Mac - there are hundreds of companies providing those plugins (many freeware products) - there are hosts by several companies. Besides Steinberg products there is NI Core and even a hardware system (that runs on Linux) - I read about projects writing those plugins successfully with free Pascal So this _is_ a good example of an OS and language independent plugin API. Maybe it's a good idea to provide something compatible. The key point is exporting the api from the executable rather than the dll. Many people don't understand this basic concept nor know it is possible, nor understand why it works and how it works. LazarusRB (arby) demonstrated this years ago with an API called Plugger. It is no longer in active development since I am very busy with web programming and consulting, and documenting Powtils project which takes most of my time. L505 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: There is open source midas.dll implementation called HyperBase. http://www.vglib.com/link-4.html It can be made compilable by FPC to different platforms... Yes, I have it since a very long time :-) But it contains bugs :/ But if there is no alternative then that would be an option. I don't understand the internals of Midas, but did help maintain a product that used 3-tier (with midas application server). Could one implement a application server using SOAP instead? I remember reading an article (I think his name was Brian Long or Dr.Bob) where he created a standalone (very simple) webserver application using Indy's server components and used that as the application server. Then connected with application clients via SOAP+HTTP. Is something like this possible with FPC? I guess the first question is, do we have a webserver component for FPC? Secondly, does FPC support SOAP? What actually happens inside the midas.dll? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Mon, 5 Nov 2007, Graeme Geldenhuys wrote: On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: There is open source midas.dll implementation called HyperBase. http://www.vglib.com/link-4.html It can be made compilable by FPC to different platforms... Yes, I have it since a very long time :-) But it contains bugs :/ But if there is no alternative then that would be an option. I don't understand the internals of Midas, but did help maintain a product that used 3-tier (with midas application server). Could one implement a application server using SOAP instead? Yes. Such a server comes even standard with Delphi. I remember reading an article (I think his name was Brian Long or Dr.Bob) where he created a standalone (very simple) webserver application using Indy's server components and used that as the application server. Then connected with application clients via SOAP+HTTP. Is something like this possible with FPC? I guess the first question is, do we have a webserver component for FPC? Secondly, does FPC support SOAP? Yes on both accounts. What actually happens inside the midas.dll? It maintains an in-memory data packet, and is able to do - local filtering - local indexing - locating data - Maintained aggregates - Save/load from file - Create and merge deltas. TClientDataset is just a wrapper around this. TBufDataset in FPC has already many of these things, but not yet all. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: Is something like this possible with FPC? I guess the first question is, do we have a webserver component for FPC? Secondly, does FPC support SOAP? Yes on both accounts. Excellent, something new to experiment with. Where could I find that webserver component? ...and thanks for the info on midas! I'm thinking of implementing some type of application server that sits on the same server (or even elsewhere) as my CGI apps. Currently my CGI apps have to grab the web variables, open a db connection, read the data, process it into a HTML page and close the DB connection. Opening and Closing DB connections tend to be slow, so if some application server can keep the connection open and just return the requested data to the CGI app, it should speed things up (I think). PS: I have no idea how you do performance/speed tests with CGI apps! This idea is all in theory. ;-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Daniël Mantione wrote: Op Sat, 3 Nov 2007, schreef Marco van de Voort: Florian Klaempfl schrieb: Ok, I'll ask next time this person to spent the weekend to fix windows installer scripts and assign to it the still open web download page, installer and install package bugs. I was never for the download system in the first place remember? In my opinion it can be a huge binary. I meant only the current download pages. Add: Each additional downloadble package increases deployment pain significantly. Just look at 9500, this problem exists for aeons, nobody cares. Probably, but is that really the problem with packages? Packages are a part of Delphi compat, and have been explicitely on the 2.x roadmap for years. And now we cancel it because the linux install installs the demoes in the wrong place, if not manually fixed? As far as I am concerned, nothing is against the implementation of packages as long as it is non-intrusive to FPC users and FPC developers. Putting something on the roadmap does not automatically mean it gets implemented, fore major features there has to be someone who has an interrest in that feature before it get implemented. Until now, it hasn't been the case. Daniël Please,do not mess fpc with packages , implement only those parts required for creating and maintaining packages by Lazarus team.Here packages are useful. Better is to implement native debugger library for fpc programs instead of using gdb which may be fine under linux but crashes too often here under windows. Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Mon, 5 Nov 2007, Graeme Geldenhuys wrote: On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: Is something like this possible with FPC? I guess the first question is, do we have a webserver component for FPC? Secondly, does FPC support SOAP? Yes on both accounts. Excellent, something new to experiment with. Where could I find that webserver component? - Webserver component is in Indy or in LNet (maybe even synapse) - Soap server in WST, (pascal webservices toolkit) it's on Lazarus CCR. ...and thanks for the info on midas! You're welcome. I'm thinking of implementing some type of application server that sits on the same server (or even elsewhere) as my CGI apps. Currently my CGI apps have to grab the web variables, open a db connection, read the data, process it into a HTML page and close the DB connection. Opening and Closing DB connections tend to be slow, so if some application server can keep the connection open and just return the requested data to the CGI app, it should speed things up (I think). It should, yes. Better yet is to write an Apache module. A breeze with FPC these days... PS: I have no idea how you do performance/speed tests with CGI apps! This idea is all in theory. ;-) Take a couple of PC's and fire wget a 1000 times on your CGI app. Better yet, use some of the FPC components (lnet, synapse) to do it in a tight loop. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: It should, yes. Better yet is to write an Apache module. A breeze with FPC these days... I know nothing about Apache modules, but from you comment, I guess I need to look into it. * Can they hold a DB connection open as well? * Are they specific to a Apache version? We are going to deploy on Apache 2.x but the minor version numbers might not always be the same. Also deployment will be on Linux and Windows servers. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
On Tue, 6 Nov 2007, Graeme Geldenhuys wrote: On 05/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote: It should, yes. Better yet is to write an Apache module. A breeze with FPC these days... I know nothing about Apache modules, but from you comment, I guess I need to look into it. * Can they hold a DB connection open as well? Yes, of course. * Are they specific to a Apache version? We are going to deploy on Apache 2.x but the minor version numbers might not always be the same. Also deployment will be on Linux and Windows servers. 2.0 differs from 2.2, but your code will not depend on it. It's a simple recompile, you could even create a single module to suit the 2 versions. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
