Re: New iChat Rendezvous Library

[Andrew W. <pr...@wi...>]

Hi Alan, Fire devs,

Glad to see you liked the plugin :-)

My quick thoughts on this...

> Part 2......
>
> The implementation Details
> --------
>
> Item #1 - 10.1 support
> ------------------------------
> One of the requirements for the proper operation of this service is 
> that it will only run on 10.2 and above (because of the requirement 
> for Rendezvous libraries in the OS)
>
> We have an interesting set of dilemmas facing us..... as we work to 
> support 10.1
>
> 1) This code will not compile on 10.1  (Unless we put in a big #ifdef 
> around a bunch of RendezvousController.m methods)
>
> 2) Currently, the services are stored as separate bundles and are 
> loaded after startup (based upon their name) the code as currently 
> constituted assumes that if a bundle is present, the service is 
> available for use.  This functionality will have to change to give the 
> iChat library an opportunity to check and see if it can run before 
> registering itself.  That might change slightly the loading of the 
> other service bundles as well.
>
> Problem #2 should be very possible to fix, but I would rather not 
> fiddle with the code to make this compile on 10.1 for 2 reasons:
>
> 1) This will result in multiple changes to the code, which will have 
> to be re-integrated every library change.
> 2) A binary built on 10.1 will not operate properly if run on a 10.2 
> system. (All the  stuff was #ifdef out.)

This sounds like a good solution overall. To keep with the goals of 
Fire running on 10.1 it would make sense if each plugin bundle is 
queried on startup as to whether it can run in the current environment. 
This will probably become more useful over time as newer versions of 
Mac OS X are released with new and cool features that you want to use 
in the plugins.

As Proteus 2.2 is a 10.2 only app I didn't have this problem with 
Proteus :-)

> Item #2 - Code modifications and the path forward
> -------------------------------
> This library is a work in progress (this current iteration is billed 
> as a beta release).  We know that there are going to be changes needed 
> to support Fire (specifically our flavors of CommunicationController, 
> Buddies, and Service). As well as additional functionality possible 
> within Fire.
>
> I would like to work out a mechanism with Andrew to make sure that we 
> don't have to do this re-integration work each time there is an update 
> to the library.
>
> I think this consists of 2 steps:
>
> 1) define a stricter line of separation between the library and the 
> integration with the rest of the application.

This is certainly something I've been intending to do, but as I was 
developing for Proteus at the time obviously fell by the way. I can't 
see any reason we can't have the equivalent of a 
ProteusCommunicationController and a FireCommunicationController or 
similar. This way both the Proteus and Fire interfaces can be updated 
as each application gains support for new features without causing 
difficulty for the other application.

For example, while Fire currently supports contacts being removed, 
Proteus does not. However, Proteus is adding support for these things, 
as Justin mentions in this post  on the Proteus forums 
(http://www.indigofield.com/forums/index.php?act=ST&f=1&t=2415) he's 
working on a lot of changes to the Service daemon in Proteus which will 
seemingly help any changes I need to make to Proteus as time goes by.

> 2) Feedback all changes into his code base, including the Fire 
> Compatible integration pieces as well (if desired)

Absolutely. I'm more than happy to have Fire and Proteus code in my 
code base.

> (Also there are a few global variables in the objects that I would 
> like to turn into instance variables)

Yeah, been meaning to get around to that kind of thing... :-) Most of 
them are throwbacks to when I copied parts of the code (which has 
pretty much all disappeared now) from other Proteus plugins.

> Item #3 - Keeping the Lawyers happy
> ----------------------------
> As we have done with other services, we will need to be cautious about 
> trademarks, so we will probably need to change the service icon to one 
> that differs from the iChat icon.  We might want to consider using the 
> Rendezvous icon, but there are some hoops to go through to get 
> permission to use that one as well.
>
> (see http://developer.apple.com/mkt/swl/agreements.html#rendezvous)
>
> The good news is that none of the terms of the logo licensing 
> agreements are onerous.  The bad news is that each new version of the 
> product has to have a separate license agreement sent to Apple.  (And 
> it has to be renewed each year.)  This is an ideal thing to have 
> EpicWare, Inc. sign if we go that route.
>
> By the way, putting a badge on the service icon is not allowed by 
> Apple's licensing guidelines.....  So if that doesn't work for us, we 
> could just make up our own similar icon, like we have for the other 
> services.

Using a completely new icon would be fine with me, if someone wants to 
make one and contribute it to the plugin. I was basically using the 
iChat icon out of lack of ability to draw... I'm sure there's someone 
out there who can make a nice icon for the service which both Fire and 
Proteus can use.

> Comments, questions anyone?
> Alan

It should be great to be working with the Fire team on this. Having 
multiple IM apps on OS X supporting Rendezvous messaging will be nice 
-- having it in Proteus has certainly saved me having to have multiple 
IM apps open, which is after all one of the big benefits of 
Fire/Proteus. Well that and the real OS X interfaces :-)

Andrew