A good analogy would be "DBI is to databases as my mystery module is to IM servers"
something that would encapsulate (or replace) existing modules like these:
anyone? bueller?
update: changed the title for clarification
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
my $im = new Net::IM;
$im->on_connect( &on_connect_handler );
$im->on_im_recv( &on_im_recv_handler );
$im->connect( 'Net::OSCAR', $username, $password );
$im->send_im( $to_user, $msg );
sub on_im_recv_handler {
my ($user, $msg) = @_;
print localtime() . "\tYou recieved an im from $user!\n\t\t$msg\n\n";
}
It's not what you look like, when you're doin' what youre doin'.
It's what youre doin' when youre doin' what you look like youre doin'!
- Charles Wright & the Watts 103rd Street Rhythm Band
Seriously - this would probably take you about a week to get working with 2 of the protocols you mentioned. Write tests. :-)
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Update:
Ooops my bad...time for a New Year's Resolution:
I will not post to public message boards during, or immediately after, any major holiday involving the consumption of adult beverages.
That being said... the notion of using relational operators to datamine IM may be interesting, assuming a fulltext index/search capability.
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 youre doin'.
It's what youre doin' when youre doin' what you look like youre doin'!
- Charles Wright & the Watts 103rd Street Rhythm Band
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.