Mickael Deloison wrote:
> 2008/8/12 Dave Page <dpage@pgadmin.org>:
>> What you advocate there sounds to me like it should be integrated in
>> the sense that it's part of our codebase, but isolated in it's own
>> project and built as a DLL to be used by pgAdmin. Which in some ways
>> gives us the best of both worlds, as Mickael could continue to
>> maintain the code outside of the pgAdmin cycle, either directly on
>> branches of the pgAdmin code, or by working on a copy from which we
>> update the pgAdmin tree periodically.
>>
>> I actually kinda like that idea...
>
> At this time, when fully integrated into pgAdmin codebase, pgScript is
> in pgadmin/include/pgscript and pgadmin/pgscript directories: so this
> quite "isolated".
>
> But, for me, the big pro of having pgScript as a separate executable
> (pgadmin3.exe and pgscript.exe) is that the operating system takes
> care of cleaning pgScript mess when this last one exits: you cannot
> have any memory leak or instability in pgAdmin because of a potential
> bug in pgScript [ I hope there is none ;-), but at this time I have
> some problems with the threads ].
>
> I think a DLL is just a way of isolating pgScript a bit more but maybe
> I'm wrong. Anyway, pgScript can be compiled as a static library
> (lipbpgs.a). I do not know how to make a DLL (never done that) but I
> guess it could be done quite easily since I can compile it as a static
> library.
It usually is. But if it's not bundled, a very clear interface has to be
defined, and it's a contract you cannot violate easily. That's what
causes DLL Hell... Which is one reason I like the tight integration.
//Magnus