Hi Neils, Subclassing NSInputStream and NSOutputStream could be an option, although you will note that there are no public interfaces for integrating them into the runloop - you can't say 'poll this file descriptor at the start of each runloop' which is what this would want to do. Instead, I was planning on using ETThread to throw the socket into a new thread and have it run in blocking mode, and push invocations back into the main thread, or run in non-blocking mode and be polled by the current thread.
The other issue with NSStream - the reason I don't use it now - is that it doesn't allow you to negotiate an SSL connection after the socket is open. XMPP needs this (so do a lot of other protocols, which is why NSStream is largely ignored), since you first connect, then request SSL mode, then negotiate the SSL connection, then log in. David On 9 Dec 2008, at 19:53, Niels Grewe wrote: > On Wed, Dec 03, 2008 at 03:01:44PM +0000, David Chisnall wrote: >> I think we might be confusing two things here. SRV records are >> used by >> some Jabber servers so they can run on a nonstandard port. You don't >> want to be implementing the DNS lookup yourself here, because your >> OS has >> a nice resolver that does it for you and exposes it via a clean, >> portable, interface. > > Hello David, > > I followed your advice and headed down the the getaddrinfo()- > road. Unfortunately it turns out that getaddrinfo() works quite > differently on different OSes: On my GNU/Linux 2.6 box with glibc > 2.7 getaddrinfo() only performes A and AAAA lookups, which gives > unintended results, naturally. But the same code, when compiled > on Mac OS Leopard, behaves as you described and looks up the SRV > records. I googled a bit and found references to the fact that > this were new behaviour in Mac OS 10.5 [1]. > So in order for SRV records to be used on all major platforms, > additional support is needed. This could either be a > roll-your-own solution (which not not advisable, I guess) or an > existing library such as ruli [2] or udns [3]. > > But apart from that I was thinking about what to do with your > ETSocket design-wise. I guess you already thought about this, but > I'll ask nonetheless: Wouldn't it be possible to subclass > NSInputStream and NSOutputStream for the task? By doing this, one > would gain support for delegates and nice integration into > NSRunLoop and what's more, there would be no need to reimplement > security-related functionality already in gnustep-base/Cocoa. > (e.g. an ETSocketSSLFilter would simply be responsible for > setting the NSStreamSocketSecurityLevelKey property of the > I/O-streams instead of doing all the SSL-stuff itself). > At least, that's what I'm judging based on a brief survey of > Apple's Stream Programming Guide -- Which is why there is > probably some obvious problem with this, ain't there? > > I'd like to avoid getting started with stuff you've already ruled > out as not feasible and would thus greatly appreciate your > comments. I hope I'm not getting on your nerves with this, since > I figure lecturing inexperienced people like me can be annoying > sometimes. So thank you for bearing with me! > > best regards > > > Niels > > [1] http://trac.adiumx.com/ticket/8404 > [2] http://www.nongnu.org/ruli/ > [3] http://www.corpit.ru/mjt/udns.html > > _______________________________________________ > Etoile-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-discuss _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
