Re^2: DBI - but for IM

no - i really have no need for sql or dbi at all, dbi is a good analogy of what i want because it lets your programs not care about which database they connect to, but abstracts out all the common stuff, like connect, prepare, execute, etc. I want something similar but for im servers, so i can write my script "IM server agnostic"

it should have functions like connect, send_im, recieve_im (callbacks..), buddy list things, etc, all the things that all im servers provide, but you don't care which im server it connects to

It's not what you look like, when you're doin' what you’re doin'.
It's what you’re doin' when you’re doin' what you look like you’re doin'!
- Charles Wright & the Watts 103rd Street Rhythm Band

Comment on Re^2: DBI - but for IM

Replies are listed 'Best First'.
Re^3: DBI - but for IM by atcroft (Abbot) on Jan 01, 2006 at 23:10 UTC
As I understand it, part of the reason for the success of DBI is the underlying DBD::* driver modules. To quote chapter 4 of Programming the Perl DBI (Alligator Descartes and Tim Bunce, O'Reilly), p. 77-78, The DBI architecture is split into two main groups of software: the DBI itself, and the drivers. The DBI defines the actual DBI programming interface, routes method calls to the appropriate drivers, and provides various support services to them. Specific drivers are implemented for each different type of database and actually perform the operations on the databases. ... Therefore, if you are authoring software using the DBI programming interface, the method you use is defined within the DBI module. From there, the DBI module works out which river should handle the execution of the method and passes the method to the apropriate driver for actual execution. This is more obvious when yourecognize that the DBI module does not perform any database work itself, nor does it even know about any types of databases whatsoever. As I read your query, and based on the DBI/DBD analogy you provide, what you are looking for is a module, for example called Net::IMI (for IM Interface). That module would contain a set of standard function/method definitions, such as connect()/disconnect(), send()/receive(), etc., and a mechanism for using an appropriate driver module for each IM service (either existing modules, such as those you listed earlier, or perhaps new set of modules, such as Net::IMD::* (for IM Driver)). It might also include a mechanism for allowing access to extended functionality that might be provided by the driver module that might not be available in all modules. While I am not aware of a project such as that regarding instant messaging (in any programming language?), it sounds as if it would be quite useful to those writing applications that might use instant messaging. I can see it taking a good bit of time and a lot of work to bring to fruition, but, if such a project were to take off, the reward of a common interface to IM functions would likely include the gratitude of numerous programmers.	[reply]
Re^3: DBI - but for IM by Anonymous Monk on Jan 01, 2006 at 18:43 UTC
I created an "Interface Manager" that encapsulates each IM service. It currently works with MSN, Oscar, Jabber (those are the services my bots connect to) and also supports IRC, AIM and CMD (however, those are much more limited). I built it over a year ago and haven't touched it since, but plan to start fleshing it out more soon. It allows you to create interfaces, passing in connection info, and then add them to the manager. With this, you can connect to multiple IM services at the same time or use it to "load-balance" your IM users across multiple bots on the same IM server. It's still fairly rough around the edges, but works and you can use it, get ideas from it and hopefully give me some feedback. Download it at http://www.botwork.com/downloads.html	[reply]