Reading a post in "public.mseide-msegui.talk", the mseide discussion list, I found this:

"Florian has committed the beginning of dynamic packages support".

With "Dynamic Packages" you mean a platform independent way of implementing something similar to
.Dlls (or .bpl)? without creating each library its own memory manager?, where objects can flow
across all libraries without problems?

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

__________________________________________________ Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

If it is finished, it would be something like this yes. However, I'am not convinced of the use of dyn. loaded packages for an OSS project so I played only with it.

Hm. I don't see what OSS or not OSS has to do with it ?

Packages are IMHO a pre-requisite for any good plugin system. It allows you to enable/disable certain features of a program based on the particular system you install the package on, without having to recompile your complete application for this particular system.

Lazarus is an IDE and therefore recompilation is IMHO an acceptable solution, since the person using it is a developer (even so, this would be too much asked for most devels in my company) but the same cannot be said for most end-user applications, OSS or not. For example, I don't think we can expect an end user to recompile XMMS if he decides to use ogg vorbis files instead of .mp3...

Apart from the recompilation issue, packages allow you to have type-safety in plugins. A normal dll does not offer this (which is why techniques such as COM are used on Windows). I could not build my day-time job application if packages did not exist...

So I do think packages are really a must; I lack the skill to implement them in the compiler, but will be glad to assist in any design issues or even creating any RTL code that you would need, if this is the problem for you.

Michael.

Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:

The reason is that the "library" construction requires you to write down your binary interface, and therefore design it properly. If the interfacing between application and plugin is automatic, it can also change automatically without you knowing.

I believe such a system is only useable in contolled environments. If plug-ins are to be developed by a third party, runtime-packages aren't a feasible mechanism.

Daniël

Packages have major drawbacks
- DLL/shared lib hell; remember each fpc build gets/needs it's own set of packages
- memory footprint of programs increase significantly since no smartlinking is possible, I created once a pure shared linked lazarus: it depended on 50 MB of shared libs.
- speed of programs decreases by ~10% because each global variable access gets indirect (like pic)
- major blow up of installer size

Then it's the task of a programmer to design a proper plugin interface. A plugin interface based on packages (in the delphi sense) requires that the main program and the plugin use exactly the same compiler and rtl.

I see only a real use of packages if one doesn't want to distribute the source of the IDE like Delphi.

Of course, if only if it ties you down to the specifics of a language. But that is not different between OSS or not OSS either.

Exactly.

Indeed.

It is exactly because I wish to control the plugins that I require packages. The single identifier space is a huge advantage, which make it almost automatic.

If you don't have packages, then you must revert to COM interfaces, refcounted stuff, explicitly sharing memory managers to be able to use ansistrings properly etc.

Packages solve all problems in 1 fell swoop. There is only 1 disadvantage to packages, this is the versioning of the base packages, which is IMHO very controllable. All other things are advantages.

In my opinion, Packages are the second best thing Borland did for RAD. If I remember the shit we had with VB and its OCXes, DLLs and whatnot. No thanks...

Michael.

I agree. I also want to remind that it is not just about the use for us. The devels will create a package system on C level in no time. It is something else for people that don't know all implementation details of Pascal/Delphi.

I don't see this as a problem. We release only once a year.

- memory footprint of programs increase significantly since no smartlinking is possible, I created once a pure shared linked lazarus: it depended on 50 MB of shared libs.

Disk footprint may be higher, but memory footprint is definitely lower. I did extensive testing on that.

- speed of programs decreases by ~10% because each global variable access gets indirect (like pic)

This is so.

- major blow up of installer size

I fail to see this ?

Yes, of course. I don't see this as a problem, but as a plus, since you control the environment.

I'm not talking about some audio decoding/encoding mechanism, that is for babies. I'm talking about hundreds of possible interfaces, highly interdependent.

If I had to design a proper plugin interface for my application at work, I would end up simply re-implementing packages, the interface would be HUGE, and would dwarf the implementation code.

Or, like I said, third party programs for which recompiling by the end user is not an option.

Michael.

Well, twice a year, but there are also snapshots, people compile there code themself etc. Each time you compile and install fpc it will fill your windows dir or /usr/local/lib with another 50 MB of dlls :)

Only because dll's/so's are probably being counted shared.

Because we've to deliever also the fpl's?

Well, but this is mainly abusing packages ;)

Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:

The memory footprint can only be lower if multiple applications are in memory that can use the same packages.

Even then, there will only be savings if the amount of code that can be smartlinked is small.

Example: Let's say an LCL package is 10MB. 2 applications are 2MB when smartlinked, and 100kb when linked against the package. (The heap can be ignored in this discussion because its memory usage does not differ depending on packages being used.)

Memory use with packages: 10MB+2*100KB = 10,2MB. Memory use with smartlinking: 2*2MB = 4MB

Daniël

Snapshots are of course not suitable; We don't support them in the first place. I also don't use development builds or Betas of Borland, although I could.

I have 1 set of BPLs on my system. Works excellent.

And for an application that needs to change compiler version - something that happened on my day-time job once in 8 years, this is not a problem.

No, because they have a single memory area.

The package system will solve this nicely, because we'll only distribute sources anyway. By the end of this year, I hope that you'll be convinced of that :-)

On the contrary, it is using them for what they were designed to accomplish.

Make no mistake:
I am not the only one using them like that. Beside my own articles about it, there have been several description of such systems in e.g. Toolbox.

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, but you should also be open to the idea that there are areas where they are simply a very good thing, making development much easier. Not everyone is a seasoned compiler developer like we are, and packages make it possible for less-educated developers to participate in more complicated architectures, because they don't have to worry about creating interfaces, ref counting, setting memory managers and whatnot. I cannot even begin to explain to some of my collegae what an interface is, they even barely understand classes. And because of Delphi's RAD approach and the use of packages, they don't have to...

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.

Michael.

Yes. And if my 500GB disk will be filled up with snapshots in 500GB/50MB=10000 days, I'm sure in 27 years, the same HD will be a lot cheaper.

Aside from the fact it makes sense to routinely install compatible versions. Keep release + 1 snapshot just like with the compiler.

> Disk footprint may be higher, but memory footprint is definitely lower. > I did extensive testing on that. Only because dll's/so's are probably being counted shared.

To be honest, all this diskspace/memory stuff is totally uninteresting. Packages are about dividing the Pascal program up in blocks, with parts being compilable AFTER the main program, without a lot of additional demands (or need for control) on the interfaces between the packages.

Don't get too worked up about plugin architectures in the AutoCAD sense. In practice it is way simpler, like only shipping one BPL to a custom if he @( paid for it. This means you can have one main binary, in which a hand full of acquisition BPLs register themselves.

If it really is that of a problem, you only deliver them using a optional package.

No it is not. If the interface is not a focus of your design, it is a waste of time to spell it out, and keep the packages independant programs.

Most notably since that fails miserably on Linux atm, since RTL duplication isn't handled very well.

_ADDRESS_ space use. Memory use depends on actual usage, since the pages of memory mapped DLLs will only be loaded on access. (and afaik linux does it similarly)

You forget something, see below.

This is wrong for plugins, see below.

Memory use with packages: 10MB+2*100KB = 10,2MB. Memory use with smartlinking: 2*2MB = 4MB

First of all, we would be stupid to create a single LCL package. We should divide it into various packages grouping units according to functionality. Even Borland realized this eventually. Secondly, your quoted sizes are simply bogus; This is not a valid argument for a discussion.

But that is beside the point.

I agree with you that for a single app, using packages is a bad thing for memory usage. No discussion there.

But the gain is not there. The gain I mentioned comes when using plugins.

With DLLs plugins, each DLL will of necessity have a lot of common code, loaded into memory with each plugin. With packages, all code is in memory only once.

Then, you are only considering code size. This is not enough. I am also considering heap size. With DLLs, each DLL will of necessity have a lot of common data structures in memory, copied in each plugin. You would be surprised at the size of this. For a system with 100ds of interfaces, this can become a big amount.

Using packages for plugins, the code will be there only once, and the common data structures in memory will be there only once. This is the gain I was talking about. It exists only for a plugin system, and when compared to a plugin system based on DLLs.

Michael.

Because you use only one delphi version.

?

I fear somehow the deploying and maintainance of packages because of the reasons mentioned: size, versioning, different code generation etc.

See irc ;)

Who will maintain this?

The person that will otherwise have to explain to newbies how to pass as string to a dll.

This is actually more or less what I would have liked to get through, yes.

Thanks Marco :-)

Michael.

So, it is actually commercially driven and therefore not a thing you look for in a OSS environment ;-)

Vincent

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.

Op Sat, 3 Nov 2007, schreef Marco van de Voort:

True, but does that change this calculation? I.e. if 75% of the code is in memory, the calculation still results in the same conclusion. Or is there, according to you, a reason why smartlinked programs have higher loading percentages than dynamically linked programs?

Daniël

No. It is time driven. And we don't code everything in plain C in OSS either. So why limit ourselves to that with library interfaces?

If the percentage is the same yes, but since the packages one has a higher percentage of unused code, the unused pages percentage will also be higher.

Or is there, according to you, a reason why smartlinked programs have higher loading percentages than dynamically linked programs?

Yes. They contain code that is more or less likely to have a chance to be really used. The "bloat" in the packages scenario doesn't.

And such a LCL bpl would be roughly have the TEXT symbols of each component in order, and an bunch of unused components would lead to unused pages.

[ Charset ISO-8859-1 unsupported, converting... ]

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.

Op zaterdag 03-11-2007 om 19:57 uur [tijdzone +0100], schreef Michael Van Canneyt:

You'll have to explain the TClientDataset to me. Do you need a symantical identical equivalent of TClientDataset?

Or do you only miss some features in sqldb?

Joost

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?

I said: packages blow up download sizes
you said: make it an optional downloadable package I say: we are even not able to maintain the current downloads and keep them bug free

Op Sat, 3 Nov 2007, schreef Marco van de Voort:

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

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...

Michael.

Op zondag 04-11-2007 om 00:34 uur [tijdzone +0100], schreef Michael Van Canneyt:

Local filtering is in TBufDataset, locate also. The packet-handling is also there?
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.

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.

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?

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?

You're right that we could make a TClientDataset which inherits from TBufDataset. But that kind of defeats the purpose of TBufDataset. 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).

Joost

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.

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.

Op maandag 05-11-2007 om 10:44 uur [tijdzone +0100], schreef Michael Van Canneyt:

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.

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)

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.

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 need the functionality ot TClientDataset, or a symantical equivalent?

On the client side you're right. But on the server side... woudn't you need both a TSQLQuery and a TClientDataset on the application-server?

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.

What does TBufDataset do more then TDataset when that property is set to True?

If you need a unidirectional dataset, don't use a TBufDataset. That's also why I once made a TSQLQuery based on TDataset.

Joost.

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

If you really want to write C plugin, then I can add a unit to the IDEIntf with some common functions without OOP.

Mattias

I understand all this, but the idea of TProvider is that the source of the data is opaque to the TClientDataset.

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.

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 need IAppProvider support, symantically equivalent.

With what you say, this should not be hard to implement, TClientDataset just needs a 'IAppServer' functionality.

Implementing TProvider would be more work.

That depends on how you want to apply the delta...

? It actually keeps a buffer with the current data. TDataset has no data buffer by itself, it only 'knows' about buffers.

If you need a unidirectional dataset, don't use a TBufDataset. That's also why I once made a TSQLQuery based on TDataset.

I understand what you're getting at. The problem is mainly that we don't know in advance whether a particular instance will be unidirectional or not. We still set it at runtime, based on some other properties.

If I would do as you propose, I would have to change one instance of TDataset with another... I need 1 component that supports both models.

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..

Michael.

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

From: "Michael Van Canneyt"

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.

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

Op maandag 05-11-2007 om 12:37 uur [tijdzone +0100], schreef Michael Van Canneyt:

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 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.

Joost

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...)

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.

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

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/

Yes. Such a server comes even standard with Delphi.

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.

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/

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

- 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.

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.

Michael Van Canneyt 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/

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.

Hi

Hi Lars,

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.

I, too, in fact don't understand this. care to give a short explanation ? I do know about FP/GNU ABI-problems, but that does not seem to be the major port of the problem.

LazarusRB (arby) demonstrated this years ago with an API called Plugger. It is no longer in active development

That is a really bad :-( . What is LazarusRB ? Is there still something usable and some documentation on LazarusRB and/or Plugger ?

since I am very busy with web programming and consulting, and documenting Powtils project which takes most of my time.

P.S.:
I did file a bug report regarding the in deed not functional "CGI-project" feature in Lazarus. I don't suppose that you are involved in that but maybe it would be a good idea to synchronize this with parts of what Powtils provides.

-Michael

Executables can export functions and procedures just like a library can.

For delphi/fpc programs.. where most people design their software inside one gigantic executable.. you already have an API stored in the exe. Taking all the code out of the exe and putting it inside DLL's takes time. When you export some procedures from the exe, you already have all that infrastructure in the exe that you can use instantly. No taking code out from the exe and putting it in dll's required.

Of course putting it into dll's is not a big deal if you have compiler support that does all this automatically with the 'compile using packages' checkbox. Exporting from the exe offers you the ability to quickly make an API for language independent plugins that can work with Digital Mars D, Freepascal, C, etc. 'Compile using packages' does not make the plugin system language independent and portable too. I'm not sure if for example delphi packages would ever dynamically load into an fpc executable. Whereas plugger ones would.

So since your executable already contains lots of code in it.. And since turning an existing big Exe into DLL's is a big pain (without compiler support), you can make use of the 'export from exe' trick that people don't know about. People think dll's are what we can export things from. Not only dll's but also exe's. This is the key to two way communication between the dll and the exe, rather than one way communication.

> LazarusRB (arby) demonstrated this years ago with an API called Plugger. It

is

> no longer in active development That is a really bad :-( . What is LazarusRB ? Is there still something usable and some documentation on LazarusRB and/or Plugger ?

Not really, just some old videos and screenshots.
The problem for me is simply lack of time :-(

They have something called 'ezcgi' and 'cgimodule' which I guess you have checked out?
But yes, more project integration is needed.. when I get fpcweb.exe working it will work with any IDE such as lazarus/mseide but even more integration is needed than just a http compiler. Things like a menu item to open a powtils template/project is needed, and much more. There are many lazarus users using Powtils and I had hoped one of them would create some template for the 'file-new..' dialog. Amir wrote a lazarus plugin I think for O-PSP development once:
https://opensvn.csie.org/pspcgi/LazarusPlugin/

L505

Freepascal, C, etc. 'Compile using packages' does not make the plugin system language independent and portable too. I'm not sure if for example delphi packages would ever dynamically load into an fpc executable.

You can't even use packages across different versions of the same compiler.

I think packages could be used to use Free Pascal object-oriented libraries in other languages.

With packages it's possible to build LCL, for example, into a DLL, create a procedural wrapper around it, and then use in any language, like is done for the Qt bindings.

I'm not saying I would do it, but packages would make this task much easier.

I may do it one day, if I see myself in a situation where I must use another language for a GUI project, well, then maybe at least I can do some bindings for LCL and keep using it =)

thanks,