General

Edit: This is not working out like it's supposed to. Still getting a svn-lock error when trying to init the sync, so while this in concept was a good idea, it's not "taking".

Pre-warning: Do not do this unless you know what you are doing, it will wipe the entireness of your SVN history for your project. It will be as if you just created your project fresh.

I wanted to svnsync an old repository to a new one on SourceForge. In my haste, I started setting up trunk/branches/tags without thinking. Of course, if the repo is not at revision 0, then you don't get to svnsync. So I pinged support to get them to reset my sourceforge repository. After a little bit, it turns out I effectively had the tools in my own hands the whole time!

I'm sure you well know that there's no way to wipe an svn repository completely down to revision 0 remotely. (at least none that I've seen so far) Well SourceForge has a nifty little tool (in your project, go under Admin, and subversion) to migrate your repository from cvs to svn. Well it didn't seem very clear on that particular page, but you can -also- migrate from an SVN dump to your new SourceForge repository from the same tool.

So how does this fit together? Basically what you do is you create a local svn repository that's completely empty:

> svnadmin create /tmp/myrepo

Then you get a dump of it:

> svnadmin dump /tmp/myrepo > svndump
* Dumped revision 0.

Then you gzip it (not sure if this is absolutely necessary):

> gzip svndump

Then upload that dump to your SourceForge file repository uploads directory, I used sftp:

> sftp USERNAME@frs.sourceforge.net
sftp> cd uploads
Connecting to frs.sourceforge.net...
USERNAME@frs.sourceforge.net's password:
sftp> put svndump.gz
Uploading svndump.gz to /incoming/U/US/USERNAME/uploads/svndump.gz
svndump.gz 100% 185 0.2KB/s 00:00
sftp> quit

Then you go to the migration tool that's mentioned under Admin -> Subversion -- Look for "Migration Instructions" and click on the migrate link under it.

You'll see the svndump.gz you just uploaded. Make sure to click the Replace checkbox and then click Submit. Wait for it to complete and you are done! Back to revision 0 for you!

I hope this helps others who run into the same issue!

I tend to see the same set of things done over and over again in clients as they go from "I only care about XMPP chatting" to "users keep asking us for better transport support". Many clients look for bare JIDs in your roster and treat them in a special manner, which is fine except in some cases I have bare JIDs in my roster and the service it's attached to is gone, so the client gets a little confused. Clients like Psi will dutifully look for jabber:iq:register and offer that as an option on services. Many of them you have to go disco browsing to find the transports available in the first place. Nothing wrong with any of that. Some clients may choose to go ahead and look for things marked jabber:iq:gateway and add them to some special list. That's not really what this is about though.

A number of clients will add in basically "hacks" for individual chat services. Psi has "service icon sets", and if it's a new service that isn't in Psi's list, it comes up with default icons. Spark has a bizarre mechanism in which it explicitly adds support for each individual transport via what I call little java "nuggets". But a common theme I see here is individually handling each service. Some new service comes along, now all of the clients have to be updated if they want to have cool icons. Personally I think that's crap. ;) I'm a big fan of dynamic lists of things. In other words a client shouldn't have to -know- about any of the specific transports. It should be able to simply pull a list of services on the server in question, if it wants gateway ones look for jabber:iq:gateway, and --- and here's the missing part --- be able to retrieve whatever it needs to provide a nice experience to the end user.

So what all tends to be custom added? Generally it boils down to icons. Icons icons icons. Icons for presence, Icons for representing the transport, etc etc. I don't think I've ever seen anything beyond icons that couldn't be determined from disco queries. So why couldn't service icons be provided by the service itself? I could see something along the lines of using pubsub where the transport publishes it's icon sets, one for service icons (maybe a set of different standardized sizes) and one for presence representation icons. That way a client could just come in and go "gimme the icons I should use" and move on. I admit my knowledge of pubsub is -still- limited, but my understanding is that there are version numbers associated with the published data, and the client could cache what it got and simply check for "is there a newer set?".

The primary caveat here that I can think of is, that pulls the 'control' of the icons away from the client and into the transport, and there's always a chance that the client doesn't "like" the icons the transport is sharing. Of course, for the most part the clients are aiming to use icons similar to those of the service the transport is providing, so they kind of already have to deal with the possibility that for example AIM's icon might not look great in their client. So the question is ... would client authors use this or just end up scoffing at icons coming from the transports themselves?

I suppose if the clients really felt like they needed to have different icons for some services, they could always override what they're getting from the transport and do their own anyway. It just always feels like a hackjob to me to see things like "if this JID matches with aim.* then use the AIM set". Especially those instances make me cringe because JIDs can be anything for those transports, where the transports -will- be providing a gateway identity that tells you flat out what service it is, assuming the transport authors bothered to follow spec. ;)

So you may recall I posted about some problems I had with IntellIJ IDEA previously ( http://blathersource.org/blog/archives/73-IntelliJ...-Can-we-talk-about-this.html ). Since that time I had managed to repair the bizarre problem with it by... well completely whacking my entire home directory configuration of it. I use a Mac so it was in Library/Application Support and Library/Caches and maybe even preferences. That said, after cleaning all of that out and restarting IDEA, the memory leak weirdness had stopped occurring and all was well. Of course I had to go reinstall all my plugins and such, but hey. So hopefully this info will help others if they ever end up running into this same problem. So uhm.. Google index this please. ;)

You also may recall that I posted about trying out Eclipse ( http://blathersource.org/blog/archives/74-Trying-Eclipse.html ). I got a lot of great comments about it, pointing me in the right direction. Plus my previous employers had a group of folk who were highly into Eclipse and had some good advice. Of course, once I got IDEA working again it was hard to argue with myself to spend time getting used to Eclipse whereas that time could be spent coding.

So flash forward to no longer working with Jive Software (as of around mid October for those who are not aware). I no longer have a license for IntelliJ IDEA, so in working with another set of projects, I found myself firing up Eclipse again and guess what ... I adore it! I feel like it really lets me really customize it to how I want it to feel, I love the level of plugin support for various things in it, and free is great. ;D I find more resources with it though. If I run into a confusion point I usually can quickly google an answer. Plus it's not hard to find a chatroom or something to pop into to talk to real people "live". If I "let go" of what I'm used to with IDEA, I actually find it more intuitive. I don't really feel like going into serious details of what I like about it compared to IDEA, but suffice to say I am highly pleased with it and likely will stick with it for future java programming. =) I actually even though of writing up a document on things I learned while converting. (like terms that IDEA uses and what they map to in Eclipse) Who knows if I'll ever write that.

I've had a couple of people ask me why I did not reapply for membership in the XSF, so I thought I might post a bit about it here. I joined the XSF about 2 years ago not really knowing what was involved in membership. No one seemed to be able to tell me anything that being a member did aside from voting on the council, or other members. In the time I spent on XSF, that is literally all I did. It seemed like all of the "important discussions" had better places to be discussed at, like the council list, the standards list, and even a few more. I think it boiled down to, what's left to talk about or even do? I don't have any interest in being a member of something just so I can say I'm a member of it, so I chose not to rejoin this year.

If there was something to being a member in the XSF that I was missing out on, please, speak up and help me understand. =) And I certainly don't have any ill feelings towards the membership, so please don't take this as a "bash". ;)

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.

The other day I was thinking about some of the folk who had requested IRC support in the IM Gateway plugin for Openfire in the past, and how they were trying to migrate from a corporate IRC server to an XMPP server. This is apparently no small task to encourage such a change and it got me pondering what could be done to make that transition smoother. In my work with IRC support and with the Martyr IRC library, I've gained a strong knowledge of how IRC works and it occurred to me that it might not be that hard to provide an IRC server that sits on top of an XMPP server and just "translates" so to speak. So instead of taking your XMPP server and having folk log in and connect to a remote IRC server, you could replace your IRC server entirely with this XMPP server that acted as both XMPP -and- IRC. At that point you might even be able to lure some people over by saying "You know, if you simply went into pidgin and used XMPP instead of IRC for the corporate server, you'd gain a lot more cool features".

Would XMPP be hard to translate into IRC? Without having written any code for it, my best gut feeling is no, not really. You'd clearly have to sacrifice some functionality, but I think you could secretly tie the two together pretty well. Log in with an IRC username and password, you're actually logging into an XMPP account on the backend with the same username and password. MUC <-> IRC chatroom. IRC WHOIS <-> XMPP vCard. IRC ISON <-> XMPP presence check (probe?). Lots of aspects map fairly well I think.

But I'm curious about interest. I mean this seems fun and I might want to whip up a proof of concept, but what if no one wants it period? I'd be wasting my time. =) So anyone listening . . . I'd love to hear your thoughts.

You know, when I first became interested in Jabber/XMPP, the thing that drew me to it so much was the concept of the transports to AIM, ICQ, etc. Why? Because it meant, instead of having to remember my passwords and accounts every time I switched to a new client, I could now store all of that on my server and log into one single location, my personal Jabber/XMPP server. In general, this has worked out well, I do not log directly into AIM/ICQ/etc unless I'm testing something or don't have another choice at the time (perhaps my transport is broken, or something of that nature).

That said, lets take a look at my Adium X list of accounts at this point. Instead of having 5 different protocol accounts listed, I have around 6 Jabber/XMPP accounts. Home server, another external server, university private server, university engineering server, livejournal, google talk, friend's server. So what happened here? My original goal was to have one and only one server to connect to. Is it because there's no XMPP transport/gateway as of yet? No, if that were the case I would have written one by now. Is it because a lot of these servers do not have s2s enabled? Some of them, yes, that is the case, but that's not why I use all of them. I can't answer why I'm now connecting to -more- accounts than I was before, completely defeating my original purpose. I also used to have a jabber.org account listed there. At least I pruned a couple.

Does it bother me that I log into so many accounts? Not really. It actually helps me keep some things in perspective while I'm developing... like the fact that I'm not the only one who does this and I should support multiple accounts in clients I might write. It does, however, limit me from being interested in clients that only support one account to connect to. Note that this is one of the other big reasons for wanting to centralize everything. If I ran into a client I liked that only could connect to one server, I could use it and be happy with it. Eh.

So anyway, no takers so far on the "anyone want to help with the Pys?". Oh well. I'll get back to them at some point.

The only problem with being in charge of or involved with open source projects is that folk start depending on something that you are only doing part time. On top of that, folk start making 'demands' on you that you can not abide by and yet continue to maintain a life outside of coding.

Why do I often find it so hard to clean up my roster? Just about anyone who has ever talked to me sits on my roster forever and I typically only end up talking to them for one or two sessions and that's it. What do I need them on my roster for? It's just causing my server extra work every time I log in!

So anyway, I spent a good couple of hours here cleaning up my roster and now it's nice and small. I'm not entirely pleased with Adium X's roster deletion handling because just about every time I deleted a roster item, it reappeared and I had to delete it again. =/ That said, it's a beta, so what do I expect. =)

Logging in is now lightning fast. I know some folk take offense at being removed from a roster, but if I removed you, this gist of it is, we don't talk much, I have no reason to need to know when you are online and/or initiate regular chats with you. Certainly doesn't mean I'm not willing to talk to you. ;)

Anyway, was kinda fun to do the housecleaning. There's a couple of legacy network contacts I still need to boot, but that involves well.... finishing adding support for that in the IM Gateway plugin. ;D [or rather, fixing it]

I'm thinking about spending a little time and packaging up PyICQt and PyAIMt into 0.8 releases. PyAIMt is more work because it means I'll be pulling over updates from PyICQt to PyAIMt, but hey, no worries.

I got to try out an eval version of Jabber XCP. I will finally have something to test XCP support with with the Pys! Yay! Setting up XCP was not entirely trivial. It took me about an hour and a half and about 80 pages of documentation. I'm not sure how much of this was postgres sucking or not, but it definitely wasn't as easy a process as I expected. That said, now that it's running, it's lightning fast. (well it's also not handling the load of my real contact list, but still) Anyway, thanks to the XCP folk for hooking me up with a copy to test against! I've always hated supporting something I couldn't test myself. ;)

I've been finding that some of these java based tools for .. well all sorts of tasks .. are quite nice. I like Jive's forum software quite a bit, I adore Fisheye... far more useful to me than websvn ever was. In fact websvn was never really useful to me. I also adore JIRA, though I must admit it's a little too "serious" for something I'd probably want to use with my Py transports. I love it for the IM Gateway plugin though. It's got a really nifty feel to it. Something else I think is really neat is that it looks like a lot of the the folk that make such products "play nice together". By that I mean, I see Jive Software (Jive Forums) using JIRA and Fisheye, Cenqua (Fisheye) using Jive Forums.. don't know if they use JIRA, the JIRA people using Jive Forums ... etc etc. Same with IntelliJ... it's just really neat to see them all using each other products. It's like one big product hug circle. =)

I'm basically in charge of Java-JML nowadays. The former developer doesn't have time for it anymore. Sourceforge is still kinda similar to how I remember it, but they do appear to have a few neat new things. =) I like the project and am certainly cool with being in charge of it. Will give me a better understanding of MSN anyway. I've applied for an open source license of IntelliJ of my own so I can make use of it with non Jive projects. At first I was tentative about this because I didn't want to start using a tool that like the original developer of java-jml couldn't use, but I based off the license, I could indeed share it with all other devs on the project. That's very cool. More importantly, I saw that the joscar folk and other such projects are using it, which gave me a lot of "ohhh other similar projects are doing it, ok then" warm fuzzy. =)

While this weekend has not really started off on a happy note, I think I might make it a release day and try to get a couple of things released today.

Well, I am pleased to say that the spam onslaught to BlatherSource has ceased. Looks like the captchas are doing the trick. Would be nice if I didn't have to resort to such measures.

On a related front, I've been storyboarding an interface for handling people submitting/updating/etc the translations for the Py transports. I think it will work out much nicer for James and I. Not sure if it'll be useful to Norman or not, but I'll contact him about it when the time comes. (unless he sees this and responds before I contact him lol)