On Jan 7, 2010, at 12:36 PM, Dave Page wrote:
> Whilst the aim is a noble one, glossing over 'it won't work on
> Windows' which is by far our most popular platform these days seems
> incredibly short sighted, and liable to lead to an endless stream of
> 'why doesn't this work' questions. It also does the module authors no
> favours, by excluding 50%+ of their potential audience, and frankly,
> isn't the way this project generally works.
That's orthogonal to the development of PGAN. The PGAN client will depend on PGXS to do the installing. If the core
implementssomething that works better on Windows, the PGAN client will use it.
> We have discussed this sort of facility at previous developer
> meetings, and as I recall came to the conclusion that we need to have
> the ability to distribute pre-built binaries, not just source code as
> virtually no Windows users are ever going to have a build environment
> setup. Similarly, neither are Mac users, if they didn't install XCode.
It's no hardship to install XCode. People do it for Perl/CPAN installs all the time.
> We also discussed extension management at the DBMS level, which I
> believe Dimitri was working on in his spare time. You should look at
> what he's been doing.
He and I have discussed it. As I wrote in the proposal, when extensions get in, the PGAN client will be updated as
appropriateto support them.
> Finally, don't write the client in Perl. Again, that's of no use to
> most Windows users. C will work on all platforms from the outset, with
> no dependencies required. Of course, the server side doesn't matter.
I'll do it in Perl because:
1. It's what I know.
2. There's a lot to draw on already (CPAN.pm, JSAN::Client, CPANPLUS)
3. JFDI.
The nice thing is that anyone will be able to write a client if they want it in some other language.
Best,
David