Re: [RFC] NSMessagePort and the NSPort hierarchy

[Alexander Malmberg]

Richard Frith-Macdonald wrote:
[snip]
> > * Moves GSTcpPort to NSSocketPort. This replaces the ... misguided
> > implementation currently there. Fortunately, this is not a problem:
> > NSSocketPort.m wasn't listed in GNUmakefile, so it has never been
> > compiled or included in the library.
> 
> Dubious... I don't think GSTcpPort does quite the same thing as
> NSSocketPort
> does in MacOS-X, so this could be misleading

No, it's not an exact match, but it is close. NSSocketPort (as
documented) is an NSPort subclass that can use arbitrary sockets.
GSTcpPort is an NSPort subclass that uses tcp/ip sockets. I don't think
filling in the missing parts would be too hard, but I haven't looked
closely at it.

[snip]
> > * Makes NSPort/NSPortNameServer return
> > NSMessagePort/NSMessagePortNameServer instances.
> 
> Very bad ... breaks OpenStep compatibility

As far as I can see, OpenStep doesn't mention NSPort at all. With some
help from #GNUstep, I found out that OPENSTEP used mach ports for
NSPort, which aren't really general inter-host ports, unless you used
PDO. In MOSX, NSPort is abstract and returns local-only NSMachPort:s. To
me, using NSMessagePort seems fairly consistent with this, although I
don't know what happened between OS and mosx, so it might be
incompatible with something there.

[snip]
> > * Since the ports are user-local, GNUstep can be used be several users
> > on the same system without name conflicts.
> 
> Conversely, they prevent sharing of information with one app supplying
> services to many users.

Matter of trust. If you really trust all users that have access to your
system, you can use the default to share things (although that would
share _everything_), or you can simply make sure to explicitly use
NSSocketPort for the things you want to share.

[snip]
> > Because of the security reasons, I think it would be good to apply this
> > as soon as possible. Some issues that need to be resolved first:
> 
> Many (most?) applications where the GNUstep base library is used
> (ie server applications rather than gui apps) expect to use DO for
> inter-host communications, and NSMessagePort is useless for that.
> As GNUstep-base is production code for many people, breaking
> DO in that way would be *very* bad.

Relying on [NSPort +port] returning any particular kind of port seems
broken, though.

> That being said, having NSApplication use NSMessagePort (by default)
> for its advertised services and for pasteboard operation is probably a
> defensible change to the behavior ... I don't think that would break
> things
> for many people.

It wouldn't be enough, though, since the distributed notification center
in -base would still be shared. This _could_ be fixed by having
NSLocalNotificationCenterType use NSMessagePort by default, though.

> Of course, if we did that, we would need a user default to turn off that
> behavior for people who expect to be able to share information.
> 
> Pragmatically then, the first priorities I see are -
> 
> 1. Alter it so that it will compile under windows!  and raise an
> informative  if any non-working code is called.

/me adds a big '#ifdef __MINGW__'...

> 2. Alter the patch so that NSMessagePort and NSMessagePortNameServer
> are not used unless explicitly asked for.
> 
> Once those changes are in place, it could go into cvs.

I still think that renaming GSTcpPort and making NSPort use
NSMessagePort is the Right Thing. The least bad alternative seems to be
to:

* Keep GSTcpPort unchanged (ie. a private class).

* Remove the current NSSocketPort implementation and replace it with a
small implementation that returns GSTcpPort:s. Most methods would return
nil (and log a warning, I guess), but this is very important since it
makes it possible to create local and remote ports without relying on
private classes (and it'd also be portable). In particular:

[NSMessagePort +port] (portably) returns a local-only port (but not
necessarily an NSMessagePort).

[NSSocketPort +port] (portably) returns a local-and-remote port (but not
necessarily an NSSocketPort).

[NSPort +port] returns some kind of port, but which kind may depend on
the platform, defaults, or other things.

* Add a default that controls whether NSPort uses NSMessagePort or
GSTcpPort. I'd prefer to have NSMessagePort be the default, but being
able to change it is better than nothing. :/ I don't think
GSMacOSXCompatible is a good choice for this default. I'm not interested
in mosx compatibility, I just want (what I consider) good behavior from
the port classes. Also, using NSMessagePort isn't particularly mosx
compatible since mosx uses NSMachPort:s.

Would this be acceptable? The defaults/NSPort thing could be handled in
a few other ways, but I think this one is the all-round best.

[snip]
> Actually, the OpenStep and GNUstep documentation is for DO as a fully
> capable networking system ... so NSMessagePort is not consistent with
> that. [snip]

NSMessagePort is not the entire DO implementation. All it does is
provide user- and system-local ports and another port "name space" of
sorts. I have tested programs that use both NSMessagePort:s and
NSSocketPort:s, and (in the final version) I haven't had any problems
with it (it needs a slight patch in NSConnection which, unfortunately, I
forgot to include in 0.5; you can get it here:
http://w1.423.telia.com/~u42308495/alex/NSConnection.patch ).

- Alexander Malmberg