Tag Archives: folk

PyAIM-t 0.6 Released!

PyAIM-t 0.6 is now available. Please note that it is sort of a stop-gap release that includes some important fixes, but also includes some very lightly tested groupchat code. I am releasing it pre-heavy testing per request of folk on the py-transports list. Major features are listed in the release notes. Enjoy! =)

PyAIM-t and PyICQ-t renamed to PyAIMt and PyICQt

Nothing major, but I’ve removed the dash from the official names of my transports. this will make them synced up with the naming schemes that PyMSNt, PyYIMt, and PyIRCt use. Note that I’m not going to be removing dashes everywhere, just in the capitalized full name of the transports. Just wanted to make sure folk were informed and not confused by the rename.

BlatherSource has moved to Clearspace!

Yes that’s right, Clearspace. Those familiar with Clearspace might be thinking to themselves … are you nuts? Clearspace is a -beast- for just a blog! Well, you’re probably right. However, I like it, I work with it, and I’ve been interested in writing some plugins for it for a long time now. The thing is, without actually running it live anywhere for myself, I never give any priority to writing said plugins. Now I have a solid reason to. =)

So what exactly -is- BlatherSource nowadays since I moved all of my projects away from it? Well, for alll practical purposes it’s my playground. I continue to use this blog for posts related to my projects, XMPP, that sort of thing. I’ll be running a number of services at this site. for example, I’m now offering public XMPP services here. If you are so inclined, feel free to register with blathersource.org. As the author of the IM Gateway plugin, there’s a good chance this will be the first place I upload new versions for testing, and if a number of folk start using the service here, it’ll help me get a window into what errors might show up. If folk start having problems that I’m having trouble dulicating myself, hopefully I can get said folk to register at blathersource.org and “demo” the misbehaving accounts to me and such. And just in general, if you are looking for a place to house your XMPP account, you are quiet welcome to register it here.

I’ll post more details on the XMPP services at a later date, but anyone is welcome to register now if they are so inclined. I’m not sure what else I’m going to run here just yet. I got a general purpose dedicated server from Hosting And Designs. I’ve been quite pleased with it so far! I hosted my previous web services at Modevia, who were wonderful! However, I decided I wanted to run more services beyond just web services, and also needed to feed my old sysadmin bug since I no longer do that for my job. =)

Anyway, I’m excited for my new site. Who knows, maybe it’ll get me posting more. Probably not, but it’s wishful thinking.

IRC and XMPP

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.

Daniel Henninger: IRC and XMPP

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.

IRC and XMPP

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.

PyAIMt and PyICQt looking for developers!

Hi folk! I just realized I never made the post here that I wanted to many months ago! As is probably clear to everyone, I just don’t have time to work on PyAIMt and PyICQt nowadays. Some day I will. Some day my interest will be reborn. But that doesn’t help anyone wanting to see work being done on it now. =) It’s certainly hard not to look at a project and think it’s stale, must be dead. That’s certainly the conclusion I jump to.

So I want to ask anyone who might be interested in joining the team so to speak and helping develop PyAIMt and/or PyICQt! Please contact me at email:jadestorm at nc.rr.com or jid:daniel at jabber.vorpalcloud.org if you are interested! Keep in mind that when I started this project I knew nothing of Python, so please don’t expect that I’m going to balk if you aren’t some sort of uber Python coder. =) Anyone who’s interested in writing code, writing documentation, learning, having some fun … whatever!

When Worlds Collide

You know, when you are working by yourself on an open source project, your schedule is your own. If you decide you don’t want to work on it for a couple of months, that’s your perogative. At some level there’s no rules what-so-ever aside from not doing things that will drive folk away from being interested in your project (assuming you care). One of the biggest things that drives the project, however, is what -you- want. When you are working on an open source project where you are teamed up with others, there’s some checks and balances over what you do and your partners do. However, at the end of the day, it’s the same type of situation, you all decide what the focus of the project will be. I don’t like to put it like this, but no one has a “right” to your time except for you.

 

When you start working with a company on an open source projects, things change. There are deadlines that the company is pushing for help drive your own timeline. There are things they’d like to see happen that you may or may not agree with. Instead of saying “well unless you submit a patch, it’s not happening”, you tend to work something out instead. It’s an interesting adjustment to “normal open source projects”.

 

Do I dislike either? No. In fact I’ve quite enjoyed the experience of it. It’s taught me a few things that I wasn’t aware of. Like I was rather blind to some of the requirements that corporations ask for. Some of the things they ask for I would typically have thought “that’s ridiculous” with some of my other projects, but here I see a lot of folk bringing the same issue up and I start to discover that the issue is more commonplace than I would have assumed. I’m not citing any examples here. Just suffice to say there’s things that having a broader knowledge of the corporate world has made me reconsider some of the decisions I might have made with other projects in the past.

 

So many thanks to Jive Software for giving me this additional experience that I wouldn’t have gotten probably with PyAIMt and PyICQt. =) It’s been fun and I hope it continues to be fun!

Daniel Henninger: When Worlds Collide

You know, when you are working by yourself on an open source project, your schedule is your own. If you decide you don't want to work on it for a couple of months, that's your perogative. At some level there's no rules what-so-ever aside from not doing things that will drive folk away from being interested in your project (assuming you care). One of the biggest things that drives the project, however, is what -you- want. When you are working on an open source project where you are teamed up with others, there's some checks and balances over what you do and your partners do. However, at the end of the day, it's the same type of situation, you all decide what the focus of the project will be. I don't like to put it like this, but no one has a "right" to your time except for you.

When you start working with a company on an open source projects, things change. There are deadlines that the company is pushing for help drive your own timeline. There are things they'd like to see happen that you may or may not agree with. Instead of saying "well unless you submit a patch, it's not happening", you tend to work something out instead. It's an interesting adjustment to "normal open source projects".

Do I dislike either? No. In fact I've quite enjoyed the experience of it. It's taught me a few things that I wasn't aware of. Like I was rather blind to some of the requirements that corporations ask for. Some of the things they ask for I would typically have thought "that's ridiculous" with some of my other projects, but here I see a lot of folk bringing the same issue up and I start to discover that the issue is more commonplace than I would have assumed. I'm not citing any examples here. Just suffice to say there's things that having a broader knowledge of the corporate world has made me reconsider some of the decisions I might have made with other projects in the past.

So many thanks to Jive Software for giving me this additional experience that I wouldn't have gotten probably with PyAIMt and PyICQt. =) It's been fun and I hope it continues to be fun!

When Worlds Collide

You know, when you are working by yourself on an open source project, your schedule is your own. If you decide you don’t want to work on it for a couple of months, that’s your perogative. At some level there’s no rules what-so-ever aside from not doing things that will drive folk away from being interested in your project (assuming you care). One of the biggest things that drives the project, however, is what -you- want. When you are working on an open source project where you are teamed up with others, there’s some checks and balances over what you do and your partners do. However, at the end of the day, it’s the same type of situation, you all decide what the focus of the project will be. I don’t like to put it like this, but no one has a “right” to your time except for you.

When you start working with a company on an open source projects, things change. There are deadlines that the company is pushing for help drive your own timeline. There are things they’d like to see happen that you may or may not agree with. Instead of saying “well unless you submit a patch, it’s not happening”, you tend to work something out instead. It’s an interesting adjustment to “normal open source projects”.

Do I dislike either? No. In fact I’ve quite enjoyed the experience of it. It’s taught me a few things that I wasn’t aware of. Like I was rather blind to some of the requirements that corporations ask for. Some of the things they ask for I would typically have thought “that’s ridiculous” with some of my other projects, but here I see a lot of folk bringing the same issue up and I start to discover that the issue is more commonplace than I would have assumed. I’m not citing any examples here. Just suffice to say there’s things that having a broader knowledge of the corporate world has made me reconsider some of the decisions I might have made with other projects in the past.

So many thanks to Jive Software for giving me this additional experience that I wouldn’t have gotten probably with PyAIMt and PyICQt. =) It’s been fun and I hope it continues to be fun!

Busy busy busy… too busy?

The problem with personal projects is just that, when the person in question gets interested in another project or busy or whatever, development stops. This is what the current status of PyAIMt and PyICQt is. I am having a lot of fun with the IM Gateway plugin for Wildfire, and as a result I don’t feel interested in putting any time into PyAIMt and PyICQt. Are these two dead now? No. I still have “things I’d like to do with them” in my head. It’s just most likely we’ll see a 1.0 version of the plugin before I touch PyAIMt and PyICQt again.

One thing that the IM Gateway plugin has brought me is that I’m now quite comfortable working with other folk on the same source code. That said, I’m trying to weigh the pros and cons of enlisting help with PyAIMt and PyICQt. There are quite a few folk that are interested in using it, a few folk who submit me patches from time to time, and certainly general interest in the transports. So my question posed is… Are there folk out there who are fairly experienced python programmers who would be interested in becoming active developers of PyAIMt and PyICQt? I am not handing off the project and will continue to be the project lead, and will continue to put development time into them as time permits. Anyway, I have not yet decided on this, I’d just like to hear from folk who might be interested in contributing. If I see some interest that’ll help drive my decision. =D

On a semi-related note, I continue to find java with an IDE to be fun and interesting. I think working with java without an IDE would be maddening due to how long it takes to compile and test things in the environment I’m using it in, and it’s certainly saved me a ridiculous amount of time in debugging stupid typos and crap. The IM Gateway plugin itself is going pretty well but unfortunately there’s a lot of work that involves working on support libraries as well. The original developer of Java-JML turned over development to me so I’ve been working on that. That’s pretty fun, I know more about the MSN protocol now than I ever expected I’d know. The Yahoo library is … kind of a pain actually. =/ Right now Yahoo is the biggest source of issues for me. Joscar for AIM/ICQ is a damn fine library, but I want to move to using a more simple API and I can’t seem to figure out how I use Joscar’s simpler API. ;) Perhaps I should like… ask them instead of just blogging about it. I tried figuring it out from Adium X but yeah… =) That’s kind of a weird setup. I need to work on implementing the old school ICQ authentication because, unfortunately, the “new style” AIM auth only works with newer accounts. (how bizarre) I’ve still got a lot to work on with IRC as right now it’s a mightily talkative transport and I doubt most folk want to see all of that. =) My biggest issue at the moment is that I’m fighting with AJAX support in the web interface. Trying to use DWR… seems like it should work fine… doesn’t. I wanted to figure this out on my own but it looks like I shall be deferring to the Jive folk to get it taken care of. So many things to do.

So anyway. Thinking back, I remember that the thing I thought was so awesome about XMPP is that the entire spec was written out and ‘open’. My first endeavour was that I like the Zephyr system from MIT and thought, based off the open protocol, that it would be neat to implement zwgc and friends except to communicate to Jabber/XMPP. This formed into JWGC. Transports came later, etc etc. The great thing is that the openness of the protocol leads to a great feeling of being able to write your own client/server/whatever to learn how it all works and go from there. The bad thing is that the openness of the protocol leads to a great feeling of being able to write your own client/server/whatever to learn how it all works and go from there. =) Now, I don’t think this truly is a bad thing, but it does lead to a -lot- of starter projects written and then ditched. I often see folk come jadmin and jdev asking about where to start in writing their own client/server/whatever, and typically they get a response of “why not just contribute to an existing project?”. If the person’s goal is to just learn, starting from the ground up is not a bad way to go. If the person’s goal is to get a server/client up and running that has X feature that all of the servers don’t have, contributing is definitely the better way to go. What’s the fine line between writing your own and not writing your own? I certainly can’t answer that. Note that I think asking “why not just contribute…” is a good way to go about it because that encourages the person to say “well I just want to learn”, at which point ok, go for it. Or it encourages us to help point the person in the right direction.

Busy busy busy… too busy?

The problem with personal projects is just that, when the person in question gets interested in another project or busy or whatever, development stops. This is what the current status of PyAIMt and PyICQt is. I am having a lot of fun with the IM Gateway plugin for Wildfire, and as a result I don’t feel interested in putting any time into PyAIMt and PyICQt. Are these two dead now? No. I still have “things I’d like to do with them” in my head. It’s just most likely we’ll see a 1.0 version of the plugin before I touch PyAIMt and PyICQt again.

 

One thing that the IM Gateway plugin has brought me is that I’m now quite comfortable working with other folk on the same source code. That said, I’m trying to weigh the pros and cons of enlisting help with PyAIMt and PyICQt. There are quite a few folk that are interested in using it, a few folk who submit me patches from time to time, and certainly general interest in the transports. So my question posed is… Are there folk out there who are fairly experienced python programmers who would be interested in becoming active developers of PyAIMt and PyICQt? I am not handing off the project and will continue to be the project lead, and will continue to put development time into them as time permits. Anyway, I have not yet decided on this, I’d just like to hear from folk who might be interested in contributing. If I see some interest that’ll help drive my decision. =D

 

On a semi-related note, I continue to find java with an IDE to be fun and interesting. I think working with java without an IDE would be maddening due to how long it takes to compile and test things in the environment I’m using it in, and it’s certainly saved me a ridiculous amount of time in debugging stupid typos and crap. The IM Gateway plugin itself is going pretty well but unfortunately there’s a lot of work that involves working on support libraries as well. The original developer of Java-JML turned over development to me so I’ve been working on that. That’s pretty fun, I know more about the MSN protocol now than I ever expected I’d know. The Yahoo library is … kind of a pain actually. =/ Right now Yahoo is the biggest source of issues for me. Joscar for AIM/ICQ is a damn fine library, but I want to move to using a more simple API and I can’t seem to figure out how I use Joscar’s simpler API. Perhaps I should like… ask them instead of just blogging about it. I tried figuring it out from Adium X but yeah… =) That’s kind of a weird setup. I need to work on implementing the old school ICQ authentication because, unfortunately, the “new style” AIM auth only works with newer accounts. (how bizarre) I’ve still got a lot to work on with IRC as right now it’s a mightily talkative transport and I doubt most folk want to see all of that. =) My biggest issue at the moment is that I’m fighting with AJAX support in the web interface. Trying to use DWR… seems like it should work fine… doesn’t. I wanted to figure this out on my own but it looks like I shall be deferring to the Jive folk to get it taken care of. So many things to do.

 

So anyway. Thinking back, I remember that the thing I thought was so awesome about XMPP is that the entire spec was written out and ‘open’. My first endeavour was that I like the Zephyr system from MIT and thought, based off the open protocol, that it would be neat to implement zwgc and friends except to communicate to Jabber/XMPP. This formed into JWGC. Transports came later, etc etc. The great thing is that the openness of the protocol leads to a great feeling of being able to write your own client/server/whatever to learn how it all works and go from there. The bad thing is that the openness of the protocol leads to a great feeling of being able to write your own client/server/whatever to learn how it all works and go from there. =) Now, I don’t think this truly is a bad thing, but it does lead to a -lot- of starter projects written and then ditched. I often see folk come jadmin and jdev asking about where to start in writing their own client/server/whatever, and typically they get a response of “why not just contribute to an existing project?”. If the person’s goal is to just learn, starting from the ground up is not a bad way to go. If the person’s goal is to get a server/client up and running that has X feature that all of the servers don’t have, contributing is definitely the better way to go. What’s the fine line between writing your own and not writing your own? I certainly can’t answer that. Note that I think asking “why not just contribute…” is a good way to go about it because that encourages the person to say “well I just want to learn”, at which point ok, go for it. Or it encourages us to help point the person in the right direction.

Daniel Henninger: Busy busy busy… too busy?

The problem with personal projects is just that, when the person in question gets interested in another project or busy or whatever, development stops. This is what the current status of PyAIMt and PyICQt is. I am having a lot of fun with the IM Gateway plugin for Wildfire, and as a result I don't feel interested in putting any time into PyAIMt and PyICQt. Are these two dead now? No. I still have "things I'd like to do with them" in my head. It's just most likely we'll see a 1.0 version of the plugin before I touch PyAIMt and PyICQt again.

One thing that the IM Gateway plugin has brought me is that I'm now quite comfortable working with other folk on the same source code. That said, I'm trying to weigh the pros and cons of enlisting help with PyAIMt and PyICQt. There are quite a few folk that are interested in using it, a few folk who submit me patches from time to time, and certainly general interest in the transports. So my question posed is... Are there folk out there who are fairly experienced python programmers who would be interested in becoming active developers of PyAIMt and PyICQt? I am not handing off the project and will continue to be the project lead, and will continue to put development time into them as time permits. Anyway, I have not yet decided on this, I'd just like to hear from folk who might be interested in contributing. If I see some interest that'll help drive my decision. =D

On a semi-related note, I continue to find java with an IDE to be fun and interesting. I think working with java without an IDE would be maddening due to how long it takes to compile and test things in the environment I'm using it in, and it's certainly saved me a ridiculous amount of time in debugging stupid typos and crap. The IM Gateway plugin itself is going pretty well but unfortunately there's a lot of work that involves working on support libraries as well. The original developer of Java-JML turned over development to me so I've been working on that. That's pretty fun, I know more about the MSN protocol now than I ever expected I'd know. The Yahoo library is ... kind of a pain actually. =/ Right now Yahoo is the biggest source of issues for me. Joscar for AIM/ICQ is a damn fine library, but I want to move to using a more simple API and I can't seem to figure out how I use Joscar's simpler API. ;) Perhaps I should like... ask them instead of just blogging about it. I tried figuring it out from Adium X but yeah... =) That's kind of a weird setup. I need to work on implementing the old school ICQ authentication because, unfortunately, the "new style" AIM auth only works with newer accounts. (how bizarre) I've still got a lot to work on with IRC as right now it's a mightily talkative transport and I doubt most folk want to see all of that. =) My biggest issue at the moment is that I'm fighting with AJAX support in the web interface. Trying to use DWR... seems like it should work fine... doesn't. I wanted to figure this out on my own but it looks like I shall be deferring to the Jive folk to get it taken care of. So many things to do.

So anyway. Thinking back, I remember that the thing I thought was so awesome about XMPP is that the entire spec was written out and 'open'. My first endeavour was that I like the Zephyr system from MIT and thought, based off the open protocol, that it would be neat to implement zwgc and friends except to communicate to Jabber/XMPP. This formed into JWGC. Transports came later, etc etc. The great thing is that the openness of the protocol leads to a great feeling of being able to write your own client/server/whatever to learn how it all works and go from there. The bad thing is that the openness of the protocol leads to a great feeling of being able to write your own client/server/whatever to learn how it all works and go from there. =) Now, I don't think this truly is a bad thing, but it does lead to a -lot- of starter projects written and then ditched. I often see folk come jadmin and jdev asking about where to start in writing their own client/server/whatever, and typically they get a response of "why not just contribute to an existing project?". If the person's goal is to just learn, starting from the ground up is not a bad way to go. If the person's goal is to get a server/client up and running that has X feature that all of the servers don't have, contributing is definitely the better way to go. What's the fine line between writing your own and not writing your own? I certainly can't answer that. Note that I think asking "why not just contribute..." is a good way to go about it because that encourages the person to say "well I just want to learn", at which point ok, go for it. Or it encourages us to help point the person in the right direction.

Busy busy busy… too busy?

The problem with personal projects is just that, when the person in question gets interested in another project or busy or whatever, development stops. This is what the current status of PyAIMt and PyICQt is. I am having a lot of fun with the IM Gateway plugin for Wildfire, and as a result I don’t feel interested in putting any time into PyAIMt and PyICQt. Are these two dead now? No. I still have “things I’d like to do with them” in my head. It’s just most likely we’ll see a 1.0 version of the plugin before I touch PyAIMt and PyICQt again.

One thing that the IM Gateway plugin has brought me is that I’m now quite comfortable working with other folk on the same source code. That said, I’m trying to weigh the pros and cons of enlisting help with PyAIMt and PyICQt. There are quite a few folk that are interested in using it, a few folk who submit me patches from time to time, and certainly general interest in the transports. So my question posed is… Are there folk out there who are fairly experienced python programmers who would be interested in becoming active developers of PyAIMt and PyICQt? I am not handing off the project and will continue to be the project lead, and will continue to put development time into them as time permits. Anyway, I have not yet decided on this, I’d just like to hear from folk who might be interested in contributing. If I see some interest that’ll help drive my decision. =D

On a semi-related note, I continue to find java with an IDE to be fun and interesting. I think working with java without an IDE would be maddening due to how long it takes to compile and test things in the environment I’m using it in, and it’s certainly saved me a ridiculous amount of time in debugging stupid typos and crap. The IM Gateway plugin itself is going pretty well but unfortunately there’s a lot of work that involves working on support libraries as well. The original developer of Java-JML turned over development to me so I’ve been working on that. That’s pretty fun, I know more about the MSN protocol now than I ever expected I’d know. The Yahoo library is … kind of a pain actually. =/ Right now Yahoo is the biggest source of issues for me. Joscar for AIM/ICQ is a damn fine library, but I want to move to using a more simple API and I can’t seem to figure out how I use Joscar’s simpler API. ;) Perhaps I should like… ask them instead of just blogging about it. I tried figuring it out from Adium X but yeah… =) That’s kind of a weird setup. I need to work on implementing the old school ICQ authentication because, unfortunately, the “new style” AIM auth only works with newer accounts. (how bizarre) I’ve still got a lot to work on with IRC as right now it’s a mightily talkative transport and I doubt most folk want to see all of that. =) My biggest issue at the moment is that I’m fighting with AJAX support in the web interface. Trying to use DWR… seems like it should work fine… doesn’t. I wanted to figure this out on my own but it looks like I shall be deferring to the Jive folk to get it taken care of. So many things to do.

So anyway. Thinking back, I remember that the thing I thought was so awesome about XMPP is that the entire spec was written out and ‘open’. My first endeavour was that I like the Zephyr system from MIT and thought, based off the open protocol, that it would be neat to implement zwgc and friends except to communicate to Jabber/XMPP. This formed into JWGC. Transports came later, etc etc. The great thing is that the openness of the protocol leads to a great feeling of being able to write your own client/server/whatever to learn how it all works and go from there. The bad thing is that the openness of the protocol leads to a great feeling of being able to write your own client/server/whatever to learn how it all works and go from there. =) Now, I don’t think this truly is a bad thing, but it does lead to a -lot- of starter projects written and then ditched. I often see folk come jadmin and jdev asking about where to start in writing their own client/server/whatever, and typically they get a response of “why not just contribute to an existing project?”. If the person’s goal is to just learn, starting from the ground up is not a bad way to go. If the person’s goal is to get a server/client up and running that has X feature that all of the servers don’t have, contributing is definitely the better way to go. What’s the fine line between writing your own and not writing your own? I certainly can’t answer that. Note that I think asking “why not just contribute…” is a good way to go about it because that encourages the person to say “well I just want to learn”, at which point ok, go for it. Or it encourages us to help point the person in the right direction.

The problem with open source

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.

PyICQ-t 0.8 Released!

I have just released a new version of PyICQ-t that includes quite a few bug fixes. It’s been a while since the last release and for a while I have been telling folk that SVN is more stable than the last release so I just wanted to get SVN packaged up in a nice way for folk to try out. One of the most important new features of this version is compatibility with Twisted 2.4 and friends.

Housecleaning

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.

Daniel Henninger: Housecleaning

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.