Sorry - I've been having problems with my mail client; I have resent the message with sensible line breaks. On 2001-02-27 06:53:05, Stig Venaas wrote: > But with for instance IPv6, you won't know what socket you need until > you're done with the resolving. That's why hostconnect() is like it > is. It even needs to connect before it knows what socket to use. That I must have missed hostconnect(). I Don't know how - I certainly remember you talking about a long time ago. > I'm not convinced we should put socket(), resolve() etc. into the > structure. I agree that we need those, and others, but I don't see > the value of putting them in a structure. I was just thinking in terms of modularity; it would mean that someone could provide support for their own weird and wonderful network transport without having to touch the core code in fsock.c. > For SSL it should be possible to connect() as usual using > hostconnect() and then do the SSL negotiation, right? Yes. > close, read and write is fine, we need that abstraction. I think > perhaps we should have destruct() rather than close() where close() > first calls destruct to let for instance SSL clean up whatever is > needed, and then do the normal socket close and free the php_sockbuf > structure. > ... > By abstracting read and write, it could be possible to > put fopen_wrappers in extensions (completely modularized), seems > sensible to me to put the SSL wrapper in the openssl extension. Yes, I was thinking along those lines too. I think what we need depends on how far we are willing to go to make the codebase nicer. Andi Gutmans suggested that it would be nice to nuke all the checks for sockets in the code; depending on how far we go towards that ideal, we might need to approach this in a different way. The problem we have is that file handles in php can be regular files or sockets, but we have to use either stdio FILEs or unix/posix sockets to represent them, and the php code has to take special steps whenever it needs to write to a file. This causes a conflict in the case of SSL enabled sockets because the thing that is passed back is neither a socket nor a FILE, but does have an underlying socket, hence the "cookie" and socketd parameters/ returns from the abstraction. If we expand the abstraction to cover regular files as well as sockets, would it be worth it? I'm going to look into it in more depth and come back with more info about where we are using this stuff and where we check for sockets, and think some more about the open/connect/construct part of it. --Wez. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
