Mac version, or non-restrictive Javascript version?

[iantresman]

1. Any chance that we might see a CGI binary for Macs, that would let us produce dual-format CDs?
2. How about allowing us to turn-off the page limit on the Javascript option?
3. Or, a platform-independent Java version?

Regards,
Ian Tresman

[David]

a) If we find someone who is an expert C++ programmer on the Mac, we will release the source code for the CGI under a NDA and they can compile a Mac version. We don't have a Mac ourselves, (at least not yet). We are currently helping to do this with the Sun / Sparc platform. So we might have a Sun CGI soon.

b) Javascript is a very limited language. In most browsers you can only allocate about 10MB of RAM using Javascript. Even if your computer has 1GB of RAM installed, it can't be used. This severly limits the size of the index file that can be opened using Javascript.

c) We looked at this but decided it would be a poor solution. With Windows XP SP2, you can no longer run Java from within a browser without jumping through a bunch of security related hoops. Whichs makes for a poor user experience.

-----
Regards
David

[Update: 7/Dec/06. The 3rd party couldn't do it. So we had to do it ourselves, but a Sun Solaris Sparc Version of the search CGI for Zoom 5 is now available]

[iantresman]

a) If we find someone who is an expert C++ programmer on the Mac, we will release the source code for the CGI under a NDA and they can compile a Mac version. We don't have a Mac ourselves, (at least not yet). We are currently helping to do this with the Sun / Sparc platform. So we might have a Sun CGI soon.

Why not put a request for a Mac person on your Home Page, there must be many who come by your site, or, put in a request at http://www.scriptlance.com/

Regards,
Ian Tresman

[David]

1) It doesn't seem fair to us that we should ask someone to do some work without offering a fair payment for that work. And becuase there isn't a big market (not many people are running Mac web servers) we can't offer much money.

2) We would need to be able maintain the software. We typically make changes to the scripts on a almost daily basis during development. And need to be able to investigate and fix bugs. So it would be better to have a in house developer when possible.

3) We already have a pretty full plate and this would take some time to arrange, test and manage.

---
David