I've been quiet for a bit.  Most of you know how blogging goes ... you get excited about it or have a lot to talk about for a time, and then you start doing less and less posting.  Though some of you are quite adept at regularly posting ... to you I give the virtual thumbs up.  =)  But what have I been up recently?  Quite a bit actually.

For those who don't know, I left my university job of 11 years at the end of October and joined Jive Software.  My work with Jive fell right in line with "what I really want to do" for my career.  =)  Plus, they're all really great people.  That said, I'm working from across the country (waves) and quite enjoying it.  Maybe Jive will open up a Raleigh-Durham (Research Triangle Park?) office at some point.  ;D ;D ;D  Anyway.  I have continued my IM Gateway work, become one of the primary developers of Openfire, and become the lead developer of Spark (amongst other things).  I've been enjoying all of these things quite a bit!  I don't get to spend a lot of time on Spark, but when I do, it's quite fun to be playing with the client side again.  It's been a loooong time.  At this point I get to play with all three of the main areas of XMPP (Client, Server, and Component)!  It didn't take that long to adapt to Jive's environment though.  I actually really dig more deadlines and scheduled releases and such.  Frankly, it helps me mind "pick a target" when I'm trying to decide what to work on next.

So what's happened to PyICQt and PyAIMt?  I've officially stepped aside.  I moved them to Google Code so that others can more easily become involved.  You can now find them at:

http://code.google.com/p/pyaimt/

and

http://code.google.com/p/pyicqt/

I haven't removed myself as one of the "owners" yet on there so that it's possible for me to facilitate others becoming involved in the project for the next month or so in case others have been dying to get involved and didn't think about approaching me before.  A couple of other folk have stepped up and are doing a few things with it!  Yay!   The new location of the py-transports "mailing list" is now a Google Group at http://groups.google.com/group/py-transports.  I must admit, at this point, I don't miss them.  I do hope that they keep going though as I do believe they are good projects.

What about the XMPP Script Repository?  Well, I moved that to SourceForge: http://xmppscriptrepo.sf.net/

I won't be actively managing it, but if you are interested in becoming involved with it, please ping me and I'll set you up!  (let me know what your sourceforge id is)  It's using a SourceForge tracker to handle new script submissions.  If people -do- submit things to it, that would be about the most maintenance it needs unless you really feel like doing some significant work with it.  So... lemme know!

So what's left of BlatherSource?  You're "looking at it".  All I'm using BlatherSource for at this point is my blog.  I may do something else with it at some point, but for now it's just my blog.  I did like the interface I had put together for it, but I just don't have time to keep developing it/to manage it, ya know?  Many kudos to my hosts at Modevia.com for putting up with my requests for the site.  =)

I do still have a site for JWGC, http://jwgc.sf.net/ (moved it to SourceForge).  No idea if I'll ever do much else with it, but I like to keep it around.  It's my first XMPP related project ever.  =)

So... why did I move PyAIMt and PyICQt to Google Code instead of SourceForge?  Well, mostly because I wanted a wiki for the documentation and I couldn't find one on SourceForge.  Of course, an hour after moving everything I found that SourceForge -does- have a wiki.  Color me blind...  Doesn't matter, was neat to see what Google Code offers in terms of services.  I really like their "easy on the end user" issues tracker.  I don't like their web space offering though.  Spaces I think it is?  Whatever it is I don't like it.  I couldn't do with it anything like what I wanted.  I hear they are looking into a better solution at some point, so that might be cool.

After looking around relentlessly or a Java OTR library .. something like libotr that Pidgin uses, I decided to request a project on SourceForge to write my own.  Hopefully others will find use in it.  It's not approved yet, but if it is, it'll be jotr.  (http://sourceforge.net/projects/jotr ?)  If anyone is interesting in helping me out with that, I would greatly appreciate it!  I was rather surprised to see nothing already exists for Java for OTR.  (then again, I could have just not found it, but I tried really hard to find it  ;D  )

The IM Gateway plugin ended up putting me in the lead developer role of Java-JML (http://java-jml.sf.net) (MSN messenger library for Java) and also a developer of Martyr (http://martyr.sf.net/) (IRC library for Java).  Things sure do pile up quick, don't they?  =)  Those have been fun though.  I've gotten to work with Smack a little more as well in my Jive work, so that's been cool.  At this point I feel like I'm touching just about everything!  lol  Who knew that I'd go from being irritated with Java to enjoying working with it so much.

Anyway, so that's what my life has been lately!  New job, new adventures, letting go of some of the old ... moving forward.  =)  Yes, I do still have some XEPs to write/propose on the backburner.  I just haven't gotten to the point where I need to write them.

In working with the IM Gateway Plugin, there has been a pressure to try to improve the way transports are handled in general.  I've begun the process of seeing what could be done to improve things, but one of the big sticking points seems to be not having the transports in your actual roster.

Now many clients provide an option to simply hide transports from your roster.  IMO, this is not a bad way to handle it.  Leaves it up to the client to decide whether to hide things or not.  It also allows for the end user to decide whether or not to see the transports or not.  I, for example, like to be able to see the transports and how they reflect when I'm logged in, what my status is, etc.  (because, for example, AIM only does available and away, none of the other statuses, and this is neat to see in my roster because I know that AIM folk don't know that I'm set to do not disturb)  It also allows clients like Psi and such to provide me a way to right click and choose log out.  (equiv of sending a directed presence packet)

So how would you go about having a transport detect that you've logged in if it's not in your roster to be telling you so?  Well you can cheat for one.  The IM Gateway Plugin allows me to use internal listeners.  This solution, of course, isn't going to help external transports a lick.  But for the plugin, it's nice.  Another way might be to require some sort of ad-hoc command to log into legacy services.  Like instead of auto-logging in, you have to select "log me in".  But then how does it detect status changes and such?  More ad-hoc commands?  Eww!  How many freakin' ad-hoc commands does it take to screw in a lightbulb.    Another way could be to create some sort of 'trust' relationship with a transport.  So a transport could indicate to it's attached server that it wants to be notified of any presence changes.  Not so sure about that either.  I think that was already addressed a long time ago in regards to transports wanting to interact directly with a user's roster.

Long story short, I think this will be fine for the IM Gateway Plugin to ditch the roster, as it apparantly confuses some folk to see transports in their list, but I don't think this is viable for other transport implementations.

That said, some issues have come up that -should- help other transports.  I'd like to, for example, write up an XEP that focuses on how to handle user preferences.  I'm not talking things like, "what theme for your client" but rather things that are handled on the server end.  For example, mail notifications.  AIM has them.  Not everyone wants them.  User should be able to go in and choose "no or yes" for mail notifications.  =)  These are enabled or disabled on the transport end and a client shouldn't be expected to have to be bothered with ignoring lots of things it doesn't want in the first place.  This is basically an ad-hoc command type of thing, but I'd like to standardize it or make it a "best practices" type of thing.  That way client devs could fairly easily go "oh this one supports user prefs, I'll provide an easy link for that".  Something like that.

Another one is a XEP that I had intended to write a while ago... basically something similar to Jabberd2's component protocol where the transport itself can connect and tell the server what jid's it wants to be.  This means that the transport could say "Hey, I'm aim.jabber, chatrooms.aim.jabber, and fries.aim.jabber" and the server could go "oh ok, well you got 'em" or "bugger off, those are taken".  Wildfire actually implemented this in a slightly different way than Jabberd2, but I think the same XEP could address both just fine.  I believe I originally called this "Extended Component Protocol" or something like that.  Who knows.  It's been a while.

On a side note, I think I figured out what was causing problems with Java-JML.  Basically I kept getting a severed connection upon logging in.  Turns out I think that the server Java-JML has for "fast login" is not a good one.  Theoretically you are supposed to connect to a nexus first and it'll tell you a login server.  I'm doing that now.

BTW, Thanks to the Cenqua peeps for providing me with a Fisheye setup for Java-JML!  I'm going to link that off the Java-JML site in a bit here.  =)  I love me some Fisheye.