Having several machines (at least a laptop and a workstation) and multiple OS’s can be a pain if you use Instant Messaging software. It usually isn’t because IM most software doesn’t allow multiple clients to be connected at the same time with the same account, but that doesn’t mean you’ll actually receive all your messages. Power failures, a rush suspend (close laptop lid and go away) or even distraction can make you lose some potentially important messages. On top of that, running the same IM account on several boxes can prove to be a mess if you wish to save the conversation logs, there is no way I know of to synchronize and centrally store all those conversations.
The only application that I believe is close to this goal is Google Chat, and I’m not even sure it completely stores all conversations, but things are really more problematic when multiple IM protocols are in use.
On the other hand, why am I limited to be connected with one client at a time? What if I’m in a big office with several workstations of my own (or even running some virtual machines). Eventually I would like to get the messages where I’m at the moment even if I just flipped my chair 180º.
This, I believe, if a nice playground for software like Pidgin (former Gaim). While there is cool software like Beagle that indexes conversations, there is still the short leap of actually storing them (all IM protocols) in a central repository, similar to Google Sync. As far as this feature goes it would be rather simple to implement, even because most of the code can be shared from Beagle.
The other feature (multiple connected clients) would be more difficult to implement as it would require a central communication server (something like Microsoft Exchange provides). Again, Pidgin would be a likely candidate for this job, and I’m certain it would be a very nice attractive for corporate users.
i actually thought about the same idea a few days ago. i have 3 computers i work on and i would appreciate it if pidgin would store the logs in a central
place..
I’m kind of old school myself and hardly ever do any instant messaging so my input is probably out of touch, but I think if I were getting more into instant
messaging I would look into meebo, http://www.meebo.com/
I’m not sure it meets any of your requirements, but it might be worth a look.
I’m considering integrating it into mojoPortal as a way
to add an easy chat feature.
Cheers,
Joe
A friend of mine, Andrew Yates, submitted a proposal for Google SOC that tackles
pretty much this very idea.. unfortunately it was not accepted. His method involved modifying a jabber server, I think, or something similar. Unfortunately I can’t find his proposal, but drop by
#l3ib on freenode and talk to us (andrewy and nightm4re) and see if we’re on the same page.
This is something I’ve been
interested in for awhile as well.
I’ve looked into it at length and believe Jabber/XMPP would be best suited to handle this. Jabber is capable of communicating with all the major IM networks via
transports (for example, AIM contacts show up to clients and can be communicated with as username@aim.jabberserver.org), can store logs on the server, supports protocol extensions, and already has
the infrastructure in place to handle this. This has the added benefit of increasing Jabber’s appeal and hopefully encouraging people to switch to it.
Several steps would be required to implement
it (not necessarily in this order):
– a XEP (Jabber’s equivalent of an RFC) detailing the protocol extension would need to be written
– support for the XEP would need to be added to at least one
jabberd
– support would need to be added to clients
I proposed this to the XMPP Foundation for the summer 2008 Google Summer of Code, but unfortunately was rejected. This is a preliminary
document I wrote up describing it: http://www.andrewyates.net/misc/xmppsync.html and here is a copy of my GSoC proposal with irrelevant information (why I want to write it, my programming background,
etc.) removed: http://andrewyates.net/misc/xmppsummary.html
As you can see, some of the supporting technologies (server-side logging in particular) are not fully implemented in all the daemons and
clients. They really need to be before a good implementation of this can be completed, so that may have contributed to my proposal’s rejection. I’m still interested in working on this, but don’t
currently have the time to. I’d still be interested if anyone else attempted it and would certainly help them sometime in the future.
Hey,
I faced the same issue and solved it to by partial
satisfaction by using ctrlproxy amd bitlbee
Ctrlproxy runs on a central server and acts as an irc proxy. Bitlbee acts as an irc server and allows access to most im networks.
By pointing
ctrlproxy to bitlbee I can have multiple irc clients connected to ctrlproxy at once all seeing the same data, with all messages logged to a central location. IRC clients generally aren’t as nice as
IM ones, but I have found ones on each platform that I am pretty happy with.
Hope that ramble made sense and is potentially helpful.
Regards,
Brett
I think Live Mesh has potential to provide a framework for solving your
problem. You use the repository as storage and it automatically syncs your clients when online. The only issue is multi presence…how does the system know which client to send a message
to?
I could live without server centralized logs and synchronized logs at
first – those would be really nice but add complexity and effort and really aren’t as important as receiving my messages everywhere I have a client connected to an IM server. Alex, I’m not clear
how a client side program like Pidgin could solve this unless it actually chooses what machines to send the messages to. I would guess it could be done by an IM server program, like a Jabber
server, that would decide where to route a message. I wish the IM server would route the message to every client that is connected for a user. If there were no server message log, each client side
message log would only show the messages actually received at that client. As for sending ‘offline’ messages (which are received at server when user not connected at all), not sure exactly how
that works today but perhaps they could be considered delivered when delivered to any client/host.
Currently I use Pidgin and connect to some type of Jabber server, and it’s very
frustrating that messages seem to randomly go to one or more (but not all) of my active Pidgin clients running on different machines. It doesn’t even seem consistent, or at least I can’t figure
out the pattern of how it chooses which machines to send the message to. Sometimes the ‘user X is typing’ message is sent to a different client than the message when it is sent which seems
bizarre.
When I googled on this subject (because I work on different machines and struggle with this issue), I saw that Sun Java System Instant Messaging has a (too) complex way of handling
this with ‘priorities’, e.g. Sun IM’s web page says:
—-
When enabled, this option allows you to select the length of time your current session is idle or away when you are inactive.
Once your status changes to idle or away, your messages are routed to the active session on a machine or device that has a higher priority.
If you are running Instant Messenger on multiple
machines, a session ID is assigned to each machine when you login. Depending on which machine you are using, you may set your session priorities such that alerts come directly to your active machine.
For example, you log onto your workstation in the morning. During a meeting, you log into your PDA and chat with a co-worker through your Java chat client. At that point, you define message
priority so that inbound messages will reach your PDA not your workstation. When you return to your office, you catch up with the Instant Messaging traffic that, by default, was routed back to your
workstation when you exited your PDA. Finally, you go home and log in from your home office, routing inbound messages to reach you at home rather than at the office. The office session stays logged
in at all times when no other higher-priority client is logged in; it receives inbound messages by default.
———— (end quote from Sun’s web page)
Personally, I wouldn’t want
to have to change a ‘priority’ every time I switched machines. It think it would be simpler and better just to route the message to every connected client for the user whether it is idle or
not.