November, 2008
Glorious Tricks w/ SourceForge
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!
Chat clients and transports: Why do I see this over and over?
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.
Thinking about Gateways
It’s been a little while since I thought much about my illustrious IM Gateway plugin for Openfire. My previous job kept me a tad too busy with other things for me to really have time for it, or be interested in spending my free time on it. Now, let me prefix this by saying I don’t have a lot of free time right now, and I may not for a while. That said, I had some time to step back and look at the IM Gateway plugin and think about some possibilities.
So first off, I don’t really know the state of the Py*t transports. Last I heard there was no one maintaining them really anymore. That is a shame as I was hoping to see them flourish outside my involvement. If that’s not true, then I certainly apologize — just know it’s because I haven’t kept up well. Regardless, I found that I prefer Java to Python for the most part anyway. So would I take those projects back if they were offered to me? Probably not to be frank.
But the IM Gateway plugin — The fact that it only works with Openfire I feel is a disservice to other server implementations, but overall it’s a very cool implementation that tackled some issues with external implementations. But if you need to restart the IM Gateway plugin, you have to take the server with it. Java seems to have a habit of being very plugin-able friendly but then easy to break things with it’s container. I’m seeing that with an application server I’m working with — it’s not hard for an app to break the application server.
So I began thinking about what core things the IM Gateway plugin does that the Pys did not. Primarily it revolves around direct internal access to user’s rosters so that things could trivially be kept in sync. Things being, nicknames, groups, actual rosters, etc. So pulling back I’m wondering how feasible it would be to do something like this:
1. Strip away the ties of the IM Gateway plugin to Openfire and make the implementation standalone
2. Take that stripped away part and turn it into a small “helper” plugin that works with the external gateway implementation to accomplish the same goals
3. Similarly, write a small “helper” plugin for ejabberd that does the same thing
4. What about other servers I don’t have interest/time to write helper plugins for? Well then the transports would act like any other external transport.
How would these helper plugins do their jobs? Well somehow they’d have to have open communication back and forth with the actual transports to manage rosters, maybe even intercept packets and munge them a bit. A little ugly but hey.
As you can probably tell, over the years I have never come up with some solution that could be formed into an XEP for all of this. At some level I continue to help that I’ll see the light through my experiments here, but I’m not holding my breath. In the meantime I’d like to see solid transports that work for everyone. Writing an ejabberd plugin would give me a real reason to learn erlang and really see what it can do.
Now, if you are someone who is excited about this concept, please understand that I don’t have a lot of time right now. I need to spend my free time on things that make me money for the time being and unless someone is dieing to sponsor this concept, I couldn’t put it ahead of other assorted things I am working on. That is not a beg for money, that is a statement of my situation and why I’m not diving into this “right now”.
I would love to hear feedback on this btw.
IntelliJ IDEA and Eclipse
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.
Why I left the XSF
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”.