Mark, et al,
Hopefully by now my next email has hit the list. Again - I would like
to apologize for my blunt response.
As for the rush to convert over to 64 bit - I thought that I had made
the reasons clear in my original posting. In order for us to use imap
functions in php we need to include reference to libc-client library.
If we can't get it to work 64 bit then everything else,
the apache web server, mysql database, etc, etc, must be built 32 bit.
That is a huge penalty for one and only one piece
software to impose on our entire deployment. The 64 bit issue in UW
imap really appears to be very basic - casting 64 bit pointers to 32
bit integers isn't going to result in the correct result runtime. The
solution doesn't seem that onerous and we would be willing to pay any
developer who would be willing to work on this. It is
that important to us.
Mark, you can have access to our Solaris 10 system 24/7 to do whatever
development and testing you deem necessary. We can also provide access
to a Solaris 2.8 system in case you want to test backwards
compatibility.
Mark Crispin wrote:
On Thu, 14 Dec 2006, Tim Mooney wrote:
In regard to: Re: [Imap-uw] 2006d Solaris 64
bit compile issues, Bob said...:
> Oh well, I pretty much expected the responses I got. Amazing how
Mark's view > along with apparently the majority of this respondents
can be so limited for > an open source package like this.
I think you should read what Mark had to say about this issue before
you jump to too many conclusions.
Thank you, Tim (and John Kelly too!).
Indeed, the problem is solely one of lack of resources. Those
resources aren't going to come any faster just because someone scolds
me over it not happening sooner.
Currently, my systems at UW (and home!) are 32-bit. NONE of them are
Solaris. Solaris support is basically a matter of groping/guessing in
the dark, with actual login on someone's Solaris system every few
years.
I also face a fairly major effort for imapd at UW which will likely
monopolize most of my work time for the next several months.
The only way, right now, that 64-bit Solaris support will happen any
faster than it would under the normal scheme of things is if either:
(1) someone contributes the necessary changes in a way that can be
deployed in the existing source without breaking existing ports.
[Hint: a massive change of code or build procedures requires
equally massive regression testing and is not likely to happen.
A small set of patches that does the minimum needed to solve the
problem in the existing framework is another matter entire.]
(2) someone gives me a 64-bit Solaris computer for my home so I have a
platform to develop/test on, and enough motivation to donate my
non-work hours to solving this problem. Solaris is always a
crapshoot, and I've currently very reluctant to change things in a
Solaris build since I don't know what I might break.
Not that I really want another computer at home (particularly not
SVR4!) and Annie would probably scream if there was something else that
stole more time away from having a life...
With all this said, it is true that I am a bit bewildered as to the
undue rush to convert to 64-bit.
Nothing in this software is likely to benefit from running in 64-bit
mode. I doubt that it would run any faster; and likely it would run
slower because more memory is consumed. 64-bits, on the surface, seems
to have only the cosmetic benefit of saying "I'm running 64-bit clean
with no 32-bit code polluting my system."
So, it is difficult for me to think of reasons why I should drop other
tasks to work on 64-bit. I think that mix administrative tools (better
conversion than mailutil, fixup tool, etc.), support for IMAP
extensions (e.g., CONDSTORE, ANNOTATE, LIST-EXTENSIONS, and especially
the LEMONADE work for mobile device support) are all of much all higher
priority.
There's only so much time in a day...or a lifetime...
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
--
Untitled Document
| Bob
Atkins |
| President/CEO |
|
Business Inter-net-working
The Cure for the Common ISP!
|
Phone: (310) 577-9450
Fax: (310) 577-3360
eMail: [EMAIL PROTECTED]
|
|
