Dan Kegel wrote:
>
> Gary Feldman wrote:
> > and b) should
> > object-oriented terminology be used in the documentation, as a pedagogical
> > tool? In other words (for the latter), perhaps the documentation should be
> > along the lines of: "A BIO is essentially an abstract class, but is
> > spe
Gary Feldman wrote:
> It occurs to me that part of the learning curve problem with respect to BIOs
> (and other aspects of OpenSSL) is that they're essentially an
> object-oriented concept implemented in C. Or to put it another way, they're
> a poor-man's polymorphism in C.
Yes, that's exactly r
Gary Feldman schrieb:
>
> specified in C. You can implement your own particular BIO (analogous to
> deriving an implementation class from an abstract class), by providing the
> following functions (i.e. methods). Since this is C and not C++, you have
> to make the methods available as follows..
> This makes me wonder whether a) perhaps a native C++ interface is in order
> (with the inherent advantages and disadvantages); and b) should
My vote is to keep things in C.
> object-oriented terminology be used in the documentation, as a pedagogical
> tool? In other words (for the latter), pe
It occurs to me that part of the learning curve problem with respect to BIOs
(and other aspects of OpenSSL) is that they're essentially an
object-oriented concept implemented in C. Or to put it another way, they're
a poor-man's polymorphism in C.
This makes me wonder whether a) perhaps a native
Jeffrey Altman wrote:
>
>
> I was just attempting to summarize what the original poster was asking
> for. I think the primary problem is that there are no example apps
> showing how to use the different types of BIOs.
>
No there isn't much, which is a pity because BIOs are very useful things
On Tue, Aug 22, 2000 at 07:44:50AM -0700, Dan Kegel wrote:
> It could well just be a lack of documentation and examples.
> The code inside OpenSSL and its existing sample apps is
> scary enough that it really takes great willpower to sit down
> and reverse engineer an understanding of how things
Jeffrey Altman wrote:
>
> > Jeffrey Altman wrote:
> > >
> > >
> > > I think what he would like is the ability to do what the Microsoft
> > > SSPI does. Instead of OpenSSL being a layer between the I/O channel
> > > and the app, he would like the app to provide all I/O functions and
> > > have
Jeffrey Altman wrote:
>
> > > I'd prefer to bypass all OpenSSL-internal buffering and I/O entirely,
> > > and let the app do all the buffering and I/O.
> >
> > Maybe, but I'm not sure what you mean exactly. Could you describe
> > in terms of an approximate example API?
>
> I think what he would
Geoff Thorpe wrote:
> Anyway, I'm out of here - hope that actually made some sense.
Thanks for the detailed reply, Geoff! It does help.
I've written the loop you described many times for other systems
(including an serial I/O interrupt handler for the IBM PC back in '82)
and there's one in my c
Jeffrey Altman wrote:
> > Jeffrey Altman wrote:
> > > I think what he would like is the ability to do what the Microsoft
> > > SSPI does. Instead of OpenSSL being a layer between the I/O channel
> > > and the app, he would like the app to provide all I/O functions and
> > > have OpenSSL provide r
> Jeffrey Altman wrote:
> >
> >
> > I think what he would like is the ability to do what the Microsoft
> > SSPI does. Instead of OpenSSL being a layer between the I/O channel
> > and the app, he would like the app to provide all I/O functions and
> > have OpenSSL provide routines that encode an
Jeffrey Altman wrote:
>
>
> I think what he would like is the ability to do what the Microsoft
> SSPI does. Instead of OpenSSL being a layer between the I/O channel
> and the app, he would like the app to provide all I/O functions and
> have OpenSSL provide routines that encode and decode buffe
On Mon, Aug 21, 2000 at 10:48:18AM -0400, Jeffrey Altman wrote:
>>> I'd prefer to bypass all OpenSSL-internal buffering and I/O entirely,
>>> and let the app do all the buffering and I/O.
>> Maybe, but I'm not sure what you mean exactly. Could you describe
>> in terms of an approximate example
OpenSSL will do networking for you only if the underlying BIO is a
socket.
The data source/sink for OpenSSL can be anything you choose. The library
comes with a few BIO implementations and if none suit your purpose, then
writing a BIO should not be very difficult as the BIO functions and
their in
Hi there,
I was lurking on this thread without replying until now because I'm damned
busy at the moment, and wasn't really sure what the beef was that started
all this ...
On Mon, 21 Aug 2000, Jeffrey Altman wrote:
> > Maybe, but I'm not sure what you mean exactly. Could you describe
> > in te
Bodo Moeller wrote:
> > I'm currently writing a multi-platform webserver using openSSL and I do also
> > experience problems with the fact that the networking code is too tighty
> > integrated with openSSL. ...
> > If openSSL would be more of a library that runs on top af a stream (any
> > stream,
On Mon, Aug 21, 2000 at 04:58:03PM +0200, Nick De Roeck wrote:
> I'm currently writing a multi-platform webserver using openSSL and I do also
> experience problems with the fact that the networking code is too tighty
> integrated with openSSL. On a unix system this may seem like a non-issue,
> but
On Mon, Aug 21, 2000 at 04:58:03PM +0200, Nick De Roeck wrote:
>>> Check my original post (I'm copying it below). We're unhappy
>>> with OpenSSL's support for nonblocking I/O on servers; currently,
>>> it either wants you to rewrite your server to let OpenSSL handle
>>> the network I/O, or use B
>> Check my original post (I'm copying it below). We're unhappy
>> with OpenSSL's support for nonblocking I/O on servers; currently,
>> it either wants you to rewrite your server to let OpenSSL handle
>> the network I/O, or use BIO pairs to let OpenSSL think it's doing
>> networking still. Nei
Right on
I also have been asking for this for a year now.
On Mon, 21 Aug 2000, Jeffrey Altman wrote:
> > > I'd prefer to bypass all OpenSSL-internal buffering and I/O entirely,
> > > and let the app do all the buffering and I/O.
> >
> > Maybe, but I'm not sure what you mean exactly. Could
> > I'd prefer to bypass all OpenSSL-internal buffering and I/O entirely,
> > and let the app do all the buffering and I/O.
>
> Maybe, but I'm not sure what you mean exactly. Could you describe
> in terms of an approximate example API?
I think what he would like is the ability to do what the Mi
On Sun, Aug 20, 2000 at 03:11:52PM -0700, Dan Kegel wrote:
> Ben Laurie wrote:
>> I've obviously missed something ... what problem are you trying to
>> solve?
> Check my original post (I'm copying it below). We're unhappy
> with OpenSSL's support for nonblocking I/O on servers; currently,
> it
[EMAIL PROTECTED] wrote:
> Yup - I think we can contain this quite easily. I'll grab the new source
> tree asap and start looking over it with you. WHere we need to start is a
> proper design for the datastructures. I like creating a group of function
> calls with a not too long mnemonic... per
> > In any event, if we design the proper underlying data structures to
> > accomodate what we want - then all we need to do is pass this data
> > structure into the proper state engine and the state engine can find the
> > parameters the low level subs need and call them. It can even do this i
[EMAIL PROTECTED] wrote:
> > Whatever we come up with, I'm sure the classic OpenSSL API could
> > be layered on top of it. Perhaps we could consider this effort an
> > experimental refactoring of the OpenSSL codebase to improve its
> > quality and reusability.
>
> I agree with this approach. Th
On Sun, 20 Aug 2000, Dan Kegel wrote:
> [EMAIL PROTECTED] wrote:
> > I agree with you 100% adn I'm in the same boat. I suggest that if we
> > can't get people on board that we just go our own way.
>
> Whatever we come up with, I'm sure the classic OpenSSL API could
> be layered on top of it
Ben Laurie wrote:
> I've obviously missed something ... what problem are you trying to
> solve?
Check my original post (I'm copying it below). We're unhappy
with OpenSSL's support for nonblocking I/O on servers; currently,
it either wants you to rewrite your server to let OpenSSL handle
the netw
I've obviously missed something ... what problem are you trying to
solve?
Cheers,
Ben.
Dan Kegel wrote:
>
> [EMAIL PROTECTED] wrote:
> > I agree with you 100% adn I'm in the same boat. I suggest that if we
> > can't get people on board that we just go our own way.
>
> Whatever we come up wit
[EMAIL PROTECTED] wrote:
> I agree with you 100% adn I'm in the same boat. I suggest that if we
> can't get people on board that we just go our own way.
Whatever we come up with, I'm sure the classic OpenSSL API could
be layered on top of it. Perhaps we could consider this effort an
experimen
I agree with you 100% adn I'm in the same boat. I suggest that if we
can't get people on board that we just go our own way. I'll be happy to
work with you on this and you can reply directly and to the list.
The problem is that at this point IMHO the product is designed to fit into
a client mode
I'm trying to integrate OpenSSL into a nonblocking
server that already has a firm idea of how it wants
to do its networking. In other words, I want to
use OpenSSL, but *do not* want OpenSSL doing any
networking for me. I also don't want to use any
huge, ungainly abstractions such as BIO pairs.
W
32 matches
Mail list logo
