Subject: Re: Proposal: socketfrom()
To: NetBSD Networking Technical Discussion List <tech-net@NetBSD.org>
From: Greg A. Woods <woods@planix.com>
List: tech-net
Date: 07/05/2007 14:24:24
--pgp-sign-Multipart_Thu_Jul__5_14:24:23_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Thu, 5 Jul 2007 02:38:54 -0400 (EDT), der Mouse wrote:
Subject: Re: Proposal: socketfrom()
>=20
> I don't like Greg Woods's idea of having process-default socket
> options, because I much prefer to have some way to name this collection
> of options, rather than having just one set of default options for a
> whole process.

I'm not so sure why having default "options" for a process is such a bad
thing.

You can change the defaults at any time again and then still create new
sockets with the "new" defaults.

The concept of "defaults" for socket options for a process already
effectively exists -- it's just that they're currently the same for all
processes all of the time.  All I'm suggesting is a way to change them,
and only for the scope of the current process and only for sockets yet
to be created.

=46rom a user's perspective it always makes much more sense to be able to
change the defaults than it does to add yet another magic way to do
something which there's already a very well established way of doing.


>  I also don't like imposing the same set of
> options on sockets of all types.

Well that wasn't actually an intention of my proposal, just a side
effect of my hasty design of the function call signature.


>  Using a socket on which they have been set isn't the
> best (it uses up a file descriptor relatively unnecessarily), but it's
> not unreasonable, and I think it's cleaner than inventing a new kind of
> API object for the purpose.

Perhaps, BUT, if the API and its semantics are not VERY carefully
thought out then the result will be that you'll have these magic new
types of file descriptors that look and feel almost exactly like every
other file descriptor.  That would be a far less than ideal result.

Jason's socketlike() [I greatly prefer dup_socket()] and the way he
described it and it was elaborated upon is the closest way I've seen
from the discussion today to avoid ending up with a magic new type of
handle that looks just like every other handle while still being able to
use a socket itself as the "template".

Other than of course my idea of just changing the current defaults.  ;-)

I agree that a new type of template object doesn't really solve anything
and just makes everything much more complicated for no good reason.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Thu_Jul__5_14:24:23_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: 2ZfybWc80lX0PIEBYOTXCPj5s2yiHfkD

iQA/AwUBRo03WGZ9cbd4v/R/EQJcRQCdEWj8j4WnLOhd+1vxngmlBfmRn54AnR6O
4yorufM15uZLsgF5pJJiRQZd
=f8H1
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Thu_Jul__5_14:24:23_2007-1--