Hi, thanks for your answer, my comments inline below...
Wan-Teh Chang <[EMAIL PROTECTED]> writes:
> > I think it's quite useful if you're trying to use NSS to SSL-ify a
> > program that does not already use NSPR.
>
> That's true. It is a quick solution that has the following constraints:
> 1. Your application should continue to work after what NSPR does to the
> native file descriptors. For example, on Unix NSPR sets the Unix
> file descriptors for sockets in non-blocking mode (i.e., setting
> their O_NONBLOCK flag).
> 2. Your application should not perform operations on the native file
> descriptors that conflict with NSPR. Take Unix as example again.
> Your application should not unset the O_NONBLOCK flag of the Unix
> file descriptors for sockets that have been imported into NSPR.
That's ok with the application I'm thinking of, I just want to provide
SSL functionality whereas only TCP functionality has been offered in
the past. (In fact, the application already sets the O_NONBLOCK flag
itself.)
> The "correct" way to SSL-ify a program that does not already use NSPR
> is to implement your own PRFileDesc. You will have to implement the
> relevant I/O methods in PRIOMethods table.
Aha! I didn't know that.
So, is this picture about right: define a PRIOMethods table that point
to my functions, use PR_CreateIOLayerStub() to get a PRFileDesc for
the new layer, which I pass as the `model' parameter when I call
SSL_ImportFD()? Then whenever the SSL layer wants to read anything,
my callbacks will be used? Seems like much additional code and
complexity without any real benefit over PR_ImportTCPSocket(), so I
might stick with it for a while.
> > (Also, RPM's would be nice. Would you accept a RPM .spec if I write
> > one, or is someone already working on it?)
>
> Nobody is working on a RPM .spec file. Do you not like the packaging
> our our binary distributions, or are RPM's more convenient?
The NSS tarball didn't include NSPR libraries, and the only binary
distribution of NSPR I found was for Java. But I did not spend very
much time searching. Anyway, RPM's are always more convenient for
RedHat Linux people.
