Joachim Staib wrote:
> I still believe that the best solution is to make the API as abstract
> (and also as extensible) as possible. There has been an idea to use
> "services" which are "resolved" at runtime, where programmers don't
> write ICQUser->SendMessage("msg", col, attribs) but something like
> ICQUser->callService("SendMessage", &specificStruct) or
> ICQUser->callService("SendMessage",
> "Message:", "MyMessage",
> "Color:", &col,
> "Attributes:", myAttributes);
On the course of my previous communication thoughts, I strongly support
Joachim's idea of making the plugin interface as abstact as possible,
especially with using symbolic names instead of linker binding:
INPUT: Some Message* msg
CODE:
string servicename = resolveServiceAspect("Messaging");
MessagingService* service = retrieveServiceInstance(msg_service);
service->SendMessage(msg);
Where msg is some message to be sent, and resolveServiceAspect and
retrieveServiceInstance are the interface to the service resolution part of
licq.
The above code may seem much more complicated than just writing
deamon->send(msg), but has the advantage of being able to plugin in any
service and even exchange it during runtime, as long as the service aspect
(here: doing the messaging stuff) is supported.
Having this dynamic binding, plugin dependencies can be modeled easily. For
example, an auto-responder plugin can depend on the presence of a plugin
providing the "Messaging" aspect.
On the other hand, a messaging plugin does not need to cope with archiving
messages. It simply sends them to a plugin implementing the "History" aspect.
If there is such a plugin, messages will be stored, if not, they will not.
Although the Dynamic Service Resolution (I like this term...) seems to blow
licq, it makes the API much more flexible, which will be a great pro for our
favourite messaging client.
--
____
/ \
/ ^ ^ \ Stefan Haun
I \/ I [EMAIL PROTECTED]
II II http://www.tuxathome.de
II II
I /\/\ I
pgpQQRVmHf82m.pgp
Description: PGP signature
