[Taking this to etoile-dev as the appropriate venue] Sorry,
I didn't mean to sound too negative about XMPP.framework. It has quite a few very nice points (I really like the MulticastDelegate stuff, it gave me one of those "why didn't I think of that?" moments) and the documentation is pretty decent. On Fri, Mar 18, 2011 at 02:33:43PM -0600, Eric Wasylishen wrote: > >> If we move away from XMPPKit to the Cocoa XMPP framework suggested by > >> Eric, I'm not sure we can make it in time. The StepChat rewriting would be > >> quite major I guess. > > > > I've looked a bit at the XMPP framework and it uses stuff like CoreData > > in a number of places. I wouldn't expect that we can port it to GNUstep > > without greater efforts. > > I don't think it would be too bad, actually. > It has some protocols for XMPP objects that need to be persistent, so you can > drop in your own storage classes. It just provides ready-made implementations > that use CoreData (in a total of about 1k lines), but there is no CoreData > dependency in the rest of the code as far as I can see. Yes, I somehow missed that the CoreData parts are meant to be replaceable. So I retract the above point. > It does use a bit of CoreFoundation, but not much. I did a search for the > string 'CF' in the codebase. There are a few CFRelease/Retain's but most of > the use is in a class called AsyncSocket which appears to be an abstraction > over CFNetwork that does authentication and related network stuff. I think we > have a similar class in David's framework so it would be a matter of > rewriting that one class. AsyncSocket is only used in XMPPStream.m so we > could maybe tweak XMPPStream to use our network abstraction, as an > alternative. I guess it is reasonable to replace it with ETSocket. One thing that we would need to add to ETSocket is the capability to associate tags with read and write operations. Another thing that would need replacing is RFSRVResolver, which uses the dns_sd API (you don't find any working implementation on non-Darwin platforms nowadays). There is a UnboundKit resolver framework in my svn branch that we can use instead. (It probably needs some cleaning up since it's one of the first pieces of Objective-C code I ever wrote) > From what I can see the code quality is pretty good; it seems quite loosely > coupled and should be as easy to port to GNUstep as it could be. I haven't > actually tried yet, though. :-) Given that my CoreData concerns have been dispelled, I tend to agree. There are some things I don't like (e.g. I've seen a bit of dot-notation here and there, and I don't think it's a good idea to handle both server-based and serverless XMPP from the same class), but I can live with that. So it might be worth the effort. Cheers, Niels _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
