|
Re: DBI - but for IM
by dragonchild (Archbishop) on Jan 01, 2006 at 15:51 UTC
|
Describe your ideal API in a reply to this post and either someone will write it or you'll realize it's so simple that you'll write it.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
|
|
I suppose it would be something akin to (nonexistent module) Net::IM - maybe read thusly:
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 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
| [reply]
[d/l] |
|
|
| [reply] |
Re: DBI - but for IM
by renodino (Curate) on Jan 01, 2006 at 16:18 UTC
|
You'll need to provide a more detailed req spec than you've given. I'm assuming you want to use SQL to access IM. But thats about all I can surmise. To start,
perhaps provide the first 3 SQL statements you'd want to use ?
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. | [reply] |
|
|
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
| [reply] |
|
|
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] |
|
|
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] |