> Microsoft just decided to make Services for Unix a free download.
Anyway, I'm coming in to this discussion late, but my 2c.
I see marginal benefit in using SFU, for considerable disadvantage.
* Users already have a postgres solution for Win32. It is called Cygwin w/
cygipc. Sure, it is not the most stable solution, but, IMHO, that's not what
prevents people from using it; it is the need to install yet-another bit of
software to support Postgres. If we want to take the fight to MySQL, again
IMNSHO, this is not the way to proceeed.
* We are close to a Win32 port already. When the last patch is applied,
there are only a few minor things to resolve (some "hard-coded" directory
issues, whitespaces in directory names), and two larger ones... namely sync
+ signals. We've believe we are onto a workable solution to signals, and I
personally think the sync issue isn't a big deal.
* I don't buy the argument that moving to SFU will remove a lot of specific
Win32 code. On what evidence is this based on? [personally, I think it'd
only get worse, again, based on little evidence]. Seems to me the bulk of
the Win32 specific code lies with fork/exec, which (unless I'm terribly
mistaken) won't be alleviated by SFU.
I too would much prefer SFU over cygipc, but, frankly, I'd much prefer this
port to go completely without either of them...
At this point, I can't see that this is anything other than a distraction.
Perhaps in the future, but well, I can't see how we'd justify it short of
being unable to suitably "fake" signals (unlikely), or being able to prove
(and that is prove, not assume) that sync performance would greatly improve
under SFU.
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>
