Attached is the log I recorded from the IRC meeting we had tonight. Only 1 other person than myself participated, but that was pretty much all I expected for the very first meeting. We will meet again next Wednesday at 20:00 or 21:00 GMT+900 (will be decided later), so if you have something to say or want to help with the future of Licq, please join at that time.
Anyways, what was discussed tonight was an overall view of the how to create a new plugin API for plugins and protocol plugins. I will be working on creating a first draft. When it is completed I will post it to the list for discussion. Jon -- ________________________________________________________ Jon Keating ICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.org GPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
--- Log opened Wed Apr 05 20:12:06 2006
20:12 <@emostar> no worries, im making dinner at the moment.. can you wait
until 21:00 for me or not?
20:13 < QnD> yes I can - but I'll have only 45 mins then. however, have your
dinner :)
20:14 <@emostar> ok, hold on ill be back in a few minutes and can start
20:14 < QnD> thanks :)
20:19 <@emostar> alright, have a few minutes till i can start eating so we can
start now... Agrajag- wanted to attend, but he wasn't sure if he could
20:20 < QnD> ah, okay
20:20 <@emostar> So mostly what we need to decide on is an api for the
plugins.. and an api for the protocol plugins
20:20 < QnD> so what to do first?
20:20 < QnD> yes!
20:21 <@emostar> the method you mentioned earlier... do you have any samples
now?
20:21 < QnD> but before doing this we should decide whether licq still shall go
the same way (multiple environments) or whether it should be restricted to qt
20:22 <@emostar> i'd prefer to have the daemon be compatible with anything
20:22 <@emostar> it allows more options and freedom
20:23 < QnD> yes, also my opinion. this will make plugin-plugin communication
regarding the GUI a bit harder, but is much cooler...
20:23 <@emostar> ive had some ideas about the plugin <-> plugin api
20:23 < QnD> cool
20:23 <@emostar> but i was thinking of talking about that after the first two
apis
20:24 <@emostar> for the api to do what we want, we first have to specify what
exactly it is that we weant
20:24 <@emostar> want*
20:25 < QnD> sorry, my telephone was ringing ...
20:25 < QnD> right!
20:25 <@emostar> and my spaghetti finished boiling ;)
20:25 < QnD> the most important first: the plugin api
20:26 <@emostar> So, here is what I want the new API to be:
20:26 <@emostar> * Supports plugins for GUI interaction (ie qt-gui, console,
20:26 <@emostar> ahh shit hold on
20:27 < QnD> *laughs* copy'npaste, copy'npaste ... the old problem :)
20:29 <@emostar> sorry.. had a stain on my new shirt and had to wash it out
quickly
20:29 <@emostar> anyways, ill continue
20:29 <@emostar> * Supports plugins for GUI interaction (ie qt-gui, console,
icqnd)
20:30 <@emostar> * Supports plugins for functionality (ie spell checker,
encryption, rss, etc)
20:30 <@emostar> * Allows the GUI to be modified within a specific range by
plugins (add menu items, add options)
20:31 <@emostar> * Do the above things in a way that makes sense so it is easy
to create useful plugins
20:31 <@emostar> * Do the above things in a way that does not excessively use
memory
20:32 < QnD> okay, sounds like good and general paradigms ...
20:33 <@emostar> now, the most basic part is how to implement the api
20:33 < QnD> for realization I'd prefer different APIs
20:34 <@emostar> different APIs for what?
20:34 < QnD> a protocol api and a general plugin api
20:34 <@emostar> ahh yes, that is definitely required
20:34 <@emostar> but it would be good to implement them in a similiar way..
20:35 < QnD> i thought about basing everything on "services", that means:
20:35 <@emostar> for example, now everything for plugins and protocol plugins
is sent through a pipe, even though they are 2 different APIs
20:37 < QnD> every plugin is an instance of a certain class that contains a
list of strings (basically), for example "message", "filetransfer", "contacts"
... when loading the host (licq) checks if there are suitable analogs and
connects them to these analogs. (bad explanation, I know)
20:38 <@emostar> hmm, so when the plugin is loaded, it will connect the
"services" that the plugin asks for, right?
20:38 < QnD> the same could be done with windows. for example the options
window is a "service" named "options". now other plugins get this window by
doing a mainPlugin->getWindowService("options"). they then get a basic window
class or something where they can change things in a certain way
20:39 < QnD> no, it connects the services the plugin provides
20:40 <@emostar> so for example, the qt-gui has a "message" protocol... that
gets connected to the daemon
20:40 < QnD> but I'm not sure how to do the _real_ communication stuff (how to
say "now send a message") ...
20:40 < QnD> right
20:40 <@emostar> then when you send a message, the qt-gui would push that to
the daemon?
20:41 < QnD> yes, to a deamon which provides the service "message" (and fits to
a user)
20:41 <@emostar> well the real communication would either be a pipe (like now),
or through exported functions
20:42 <@emostar> if the qtgui wants to send a message it will tell the daemon
to send a message... it needs to have the necessary parameters.. but then
before the actual message is sent, it will have to call any listening plugins
that may modify the message
20:43 < QnD> yes, I don't mean that. I prefer exported functions. What I mean
is the fact that if there are only abstract "services" to communicate to there
also can only be an abstract function to do that communication, something like
daemon->sendEvent("message", &messageInfo); ... maybe this is not the best
solution
20:44 <@emostar> well, abstract is nice sometimes.. but for this, i think
something more defined would be better
20:44 < QnD> hm, any concrete ideas?
20:45 <@emostar> the current plugin -> daemon communication seems to be fine...
20:45 <@emostar> just calling the sendMessage function of the daemon
20:46 < QnD> but is it extendable without changing the actual base of licq?
20:46 <@emostar> how extendable do you mean?
20:47 < QnD> that completely new protocol services could be added, like "send a
greeting card" or something like that
20:47 <@emostar> well, with the current methodology... it is not very
extendable with new events
20:48 <@emostar> i guess the abstraction would be necessary to map the concrete
protocol plugin events to be able to be sent from other plugins to the daemon
to the protocol plugin
20:49 < QnD> and that's why it might be good to make things more abstract. what
the base is doing then is nothing but handling and dispatching events and
calling plugin in the right order (1. encryption, 2. msn)
20:49 <@emostar> so what sounds best is having the plugin say it wants to do
this event and pass the parameter... the daemon then looks up the protocol
plugins for a matching event and sends it off to the protocol plugin if found
20:50 < QnD> what do you mean with "it passes the parameter"?
20:51 <@emostar> the daemon will pass the parameter (destination, message
content, etc)
20:51 <@emostar> to the protocol plugin
20:51 <@emostar> but what needs to be concrete is the way the parameter is
passed.. it will need to be the same for all protocol plugins
20:51 < QnD> sure
20:52 <@emostar> but that gets a bit complicated.. because if the daemon is
supposed to handle new events.. where is the structure of the new event coming
from?
20:52 < QnD> generaly the only thing that needs to be passed are the things a
plugin needs to know. the rest must be organized by the daemon or proto plugin
20:53 < QnD> you mean from which protocol or what?
20:54 <@emostar> well, if it is going to be abstract... the "message" event
will be abstract too, won't it?
20:54 < QnD> it will
20:55 <@emostar> but the "message" event needs to be defined somewhere so when
you make a protocol plugin, you know exactly what you are getting from the
daemon
20:56 < QnD> but shouldn't the daemon only give the same information to every
protocol plugin? maybe for a message: length, content, date, sendViaServer ...?
20:56 < QnD> the rest must be "organized" by the protocol plugin
20:57 <@emostar> yes.. but where will the information it gives be defined?
20:57 < QnD> this is a small problem indeed
20:57 <@emostar> currently the protocol plugin api has structures the daemon
passes to the protocol plugin
20:58 <@emostar> in licq_events.h you can see many classes at the bottom part
of the file
20:59 < QnD> yeah, I know most of them well :)
20:59 <@emostar> for example: CSendMessageSignal(const char *szId, const char
*szMsg, unsigned long nCID = 0);
20:59 <@emostar> currently that is all the information a plugin gets about the
emssage it is sending
21:00 <@emostar> what i propose is for the standard events, we have either a
class object to pass.. or an exported function to call with a set amount of
parameters
21:01 <@emostar> for specific events.. the protocol that supports the event can
tell the daemon about it, so it knows to pass it along
21:02 < QnD> hmyes ... if one would give the plugin a class object there was
only one or thow functions neccessary to handle the complete event-passing
21:02 <@emostar> that way we can keep it standarized for the basic events...
and then keep a level of abstraction for protocol specific events
21:04 <@emostar> for example, the protocol plugin supports an event for shaking
the window (MSN...)
21:04 < QnD> hm, .... if I understood you right this is a bit similar to the
"service"-stuff i wrote above. A plugin knows a certain service and tells the
daemon that it can handle it
21:04 <@emostar> QnD: yes :)
21:05 < QnD> so you need a kind of identification algorithm ...
21:05 <@emostar> the plugin says, 'register a "shake-window" event for me. Here
is the function you can call when it comes... " and then pass a function
pointer that contains some void *'s
21:06 <@emostar> thats very C'ish... C++ would be to use objects.. but I'm not
sure of the best way to use objects
21:06 < QnD> sounds great! that's _exactly_ what i meant above concerning the
protocol plugin side
21:07 <@emostar> using strings to identify should be fine
21:07 < QnD> yes
21:07 <@emostar> there are many small details to work on, but thats for later..
first we need a very high level plan
21:07 < QnD> yes again
21:08 < QnD> another question is: how does the protocol plugin send e.g. a
"shake window" event (which it just detected/decrypted) to the gui plugin
21:09 <@emostar> so, I guess I will spend some time creating a draft of the
this kind of system
21:10 <@emostar> the plugin will have to tell the daemon it has an event, and
pass the information to the daemon via a void pointer * or some generic class
(will do some research about doing this in classes first and then decide)
21:10 < QnD> sounds good. I think a GUI api can only be nased on this, so
thinking about it should be started when your drafts are ready
21:10 < QnD> nased -> based
21:10 <@emostar> then the daemon should just push it to all plugins... there
can be an option to tell the daemon to send it protocol specific events (like
"shake-window")
21:11 <@emostar> of course the plugin will have to be expecting this event..
(how else could it physically shake the window? ;)
21:11 <@emostar> so the load of supporting all the features of the different
protocols will be focused on the plugins
21:12 <@emostar> currently when there is a new function to add to a protocol it
is added to the daemon first...
21:12 <@emostar> then the protocol plugin..
21:12 <@emostar> then the gui plugin...
21:12 < QnD> for dependability, performance and memory reasons I'd prefer to
make a function where plugins can subscribe to a certain type of event
21:12 <@emostar> with this services based api, the daemon will be removed from
the scene
21:13 <@emostar> ahh yes, the plugin will subscribe to "shake-window" evne
though the daemon doesnt know a thing about it.. it can still connect it
21:14 < QnD> exactly! and when the proto plugin says "here is a
'shake-window'"-event it connects it to the the window that subscribed to this
event
21:14 <@emostar> hmmm im not sure about windows... if the daemon is gonna
connect it to a window, then the daemon is assuming the plugin has a window..
21:15 <@emostar> i think the daemon should connect it to with whatever the
plugin wants
21:15 < QnD> in fact it only connects a certain amount of events to a kind of
callback function
21:15 <@emostar> for example.. i think "shake-window" is annoying so i make a
plugin that sends you back 3 "shake-window" for every 1 i get from you ;)
21:16 < BadSTuff> hello.
21:16 -!- mode/#Licq [+v BadSTuff] by ChanServ
21:17 <@emostar> CICQDaemon::connectToProtocolEvent(const char *szEvent, ....);
21:17 <@emostar> BadSTuff: hello
21:17 < QnD> yes.... what the window could have then is such a callback
function it evaluates when a new events is received. maybe it says
daemon->subscribe(func, "message", "shake-window");. also a
"revenge"-shake-plugin could do this but doesn't need a window
21:18 <@emostar> hmmm what would be the "message" in the above example?
21:19 < QnD> the function says "subscribe the events: message and shake-window
and send these events to the function func"
21:20 < QnD> after the first parameter a list is started with all required
events
21:20 <@emostar> hmm the only problem is that the function "func" would have to
see if it is getting a messsage or a shake-window
21:21 < QnD> thats true ...
21:22 < QnD> but a new callback function for every event would be too much I
think
21:22 <@emostar> there are some that are similar so they can be grouped
21:23 <@emostar> like AddUser, RemoveUser ... the difference is so small... one
adds to a list one removes.. that can be done by a flag
21:23 <@emostar> but then shake-window and message.. they are quite a bit
different.. but perhaps a flag would be needed
21:24 < QnD> yes ... so the daemon would then call the callback function with
something like func("add/remove user", EVENT_REMOVEUSER, data); or so
21:25 <@emostar> yeah, something like that would work
21:26 <@emostar> for basic events "send-msg" "recv-msg" "add-user" "del-user"
those structures would be defined by the daemon
21:27 < QnD> in icqnd every event is called with the function: gboolean
IMEventFunc(type, subtype, result, info, data); maybe something like this would
be enough
21:27 <@emostar> or i guess another way would be to define the structures in
documentation
21:27 <@emostar> and have the plugins comply with that.. and the daemon doesn't
need anythign defined
21:27 < QnD> yeah!
21:27 <@emostar> that would make it more abstract than what i was thinking of
21:28 < QnD> i thought that WAS what you meant ...
21:28 <@emostar> not at first
21:29 < QnD> ah
21:29 < QnD> but I think it's more extendable and gives more freedom. with a
good documentation working with this API will be quite easy
21:30 <@emostar> yes... of course, the time frame before the api gets completed
will be a bit in the future
21:31 < QnD> yes ... there's another thing (which is more specific) I wanted to
talk about: user information
21:31 <@emostar> the plugin needs to know some thing about the protocol though
21:31 <@emostar> for example, what status does the plugin support...
21:31 <@emostar> yes... let me guess.. the ICQUser class?
21:32 < QnD> 100 points for the right answer :)
21:32 <@emostar> hehe.. each protocol does have different parts of user
information
21:33 < QnD> to cope with all these problems in a more abstract way there
should be a function for every window/plugin part to get a kind of information
struct or class for a protocol. maybe something like LicqProtoInfo*
LicqUser->getProtocolInfo();
21:34 < QnD> or better: LicqUser->protocol->getInfo();
21:34 <@emostar> and what exactly do you think should be returned?
21:34 < QnD> hm ... information :)?
21:35 < QnD> maybe some kind of list of supported status fields, a bit list of
supported info, the name of the proto, server info ...
21:36 <@emostar> hmm yeah..
21:37 < QnD> the main window then gets all possible statuses by asking the
owner->protocol->getProtocolInfo();
21:37 -!- wwp [EMAIL PROTECTED] has quit ["memory overload"]
21:37 -!- wwp [EMAIL PROTECTED] has joined #licq
21:37 <@emostar> yeah.. that sounds better
21:38 <@emostar> i guess i will have to write up a first draft soon
21:38 < QnD> ... generally I think all protocol stuff should be done there (as
it already is partially), something like
ownerForMyMSNAccount->protocol->setStatus()
21:38 -!- wwp [EMAIL PROTECTED] has quit [Client Quit]
21:39 <@emostar> that looks like one of the goals i missed out earlier: support
more than one owner per protocol
21:40 < QnD> oh, right ... every owner then has another instance of the
protocol which is completely independant from other instances
21:41 <@emostar> yes.. that is something id like.. and brings up more
complications
21:42 <@emostar> but we shoyuldnt worry about those details yet
21:42 < QnD> exactly!
21:42 < QnD> alright, I have to go now
21:42 <@emostar> when can you meet again?
21:42 < Agrajag-> hey guys sorry i couldn't make it. hope to read the logs
later and i'll post to the list with stuff. gotta go, cya
21:42 < QnD> very productive chat, indeed!
21:42 <@emostar> Agrajag-: no worries, see ya later
21:43 <@emostar> QnD: yes, i feel that i have some stuff to make a first draft
that we can then work on the next time
21:43 < QnD> hm, not sure ... the problem is that it's late at night at you
when it's evening here :)
21:43 < QnD> think the first possible time will be next wednesday, same time
21:43 <@emostar> yeah, big time difference..
21:44 <@emostar> alright, ill post something to the mailing list before then..
you can reply there.. most of the work will have to be done on the ML it looks
like
21:44 <@emostar> since once a week, having a chat is good.. but cant depend
only on the chats
21:45 < QnD> yes, of course.
21:45 < QnD> maybe one could talk about icq if there is something "urgent". my
number is 82493208. (i have yours :])
21:45 < QnD> see you then
21:46 <@emostar> alright, well ill talk with you later
21:46 < QnD> alrighty
21:46 -!- QnD [EMAIL PROTECTED] has quit ["... und tschüß"]
21:49 < Rapp> heyo. missed the meeting, because of lunch, but i managed to save
a transcript :)
21:50 < Rapp> gotta read it tonight or something -- regular meetings are a good
idea. the blender coders for example meet regularly on sundays and it helps in
organising stuff.
22:00 <@emostar> yeah, ill post a transcript soon on licq-devel
22:01 <@emostar> yeah, hopefully we can get some more developers ;)
--- Log closed Wed Apr 05 22:04:01 2006
pgptRTBcYShit.pgp
Description: PGP signature
