[prev in list] [next in list] [prev in thread] [next in thread] 

List:       licq-devel
Subject:    [Licq-devel] Licq Meeting 2006-04-26 (#4)
From:       Jon Keating <jon () licq ! org>
Date:       2006-04-27 12:21:56
Message-ID: 20060427122156.GB7240 () licq ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


Sorry for the delay with the meeting notes and log.

The meeting started and ended a bit earlier than usual. My apologies to
anyone that missed out on the beginning part. Here is a summary of what
was discussed:

  * The GeneralPlugin class was discussed a bit and some modifications
    are planned.

  * Some ideas about how user information is stored and shown in the
    GUI of all the plugins were discussed. This isn't done and still
    needs some more work. I will do some research to see how much of a
    performance hit we will take if use a structure like CEventData for
    the user information as well.

  * Some explanations about the current classes in the Licq Wiki were
    explained a bit.

I would also like to say that the new development branch should try to
make as best use of the STL as possible. The current release of Licq
uses the STL a little bit, mainly because at the time it was written
(1999) the STL was not completely supported on the compilers. But now
all modern compilers support it. I'd also like to see the Boost
(www.boost.org) libraries used were applicable.

The goal is to make it as generic and extend-able as possible to support
many plugins including a sort of plugins of plugins (for example.. to
support video chat). It should be able to be done with C++ using the
modern tools available now. I have a few new books to read that should
also help me out to make better design decisions.

Jon


--=20
________________________________________________________
Jon Keating                ICQ: 16325723
jon@licq.org               MSN: keating_jon@hotmail.com
http://www.licq.org        GPG: 2290A71F
http://www.thejon.org      HOME: Minamiashigara, Japan

["licq-meeting_20060426.txt" (text/plain)]

--- Log opened Wed Apr 26 19:45:42 2006
19:45 <@emostar> Ok, lets start the meeting
19:46 <@emostar> It's a little early, so people will join us as we progress
19:46 <@emostar> So, yesterday I started a new branch in SVN and started working on \
the new source files 19:47 < QnD> yes, okay ... enough time ti ask questions about \
the LicqCallback-thing you wrote. I must confess that my C++-knowledge doesn't go \
that far, so I don't understand anything ... 19:47 <@emostar> There are many things \
to change, so it will take some time before we get a working version completed 19:47 \
< QnD> ti = time 19:47 <@emostar> ok.. are you looking at the wiki now?
19:47 < QnD> yes
19:48 <@emostar> the LicqCallback definition?
19:48 < QnD> yes ...
19:49 <@emostar> so the class for callbacks that will be used is the LicqCallback \
class. its a templated class so it will support any object and any function 19:50 \
<@emostar> that way the plugins can specify their object and the member function in \
that class 19:50 <@emostar> and the daemon doesn't have to know anything about the \
object 19:50 < QnD> hm ... can you give an example?
19:50 <@emostar> theres one on the wiki :)
19:51 < QnD> really :)? one moment ...
19:51 <@emostar> LicqCallback *pObject = new \
LicqCallback<CClass>("user-status-change", this, CClass::handleStatusChange); 19:51 \
<@emostar> pDaemon->registerCallback(pObject); 19:51 < QnD> oh, yes, there ...
19:52 < QnD> and what does "operator" mean?
19:52 <@emostar> do you understand the example?
19:53 <@emostar> void operator()(void *) is the () operator
19:53 <@emostar> we overload it
19:53 < QnD> yes, I do ... although I always thought that only static member \
functions of a class can be set as a parameter 19:53 < QnD> why do you overload it?
19:54 <@emostar> to make calling the object easier.. there has to be a way to execute \
the callback 19:54 <@emostar> so it can be done like object(param);
19:55 <@emostar> otherwise we have to add a member function to execute it.. liek \
"run" 19:55 <@emostar> so then it would be object.run(param);
19:55 <@emostar> but the () operator is meant to run a function.. so its best to use \
it 19:56 < QnD> aah! I remember ... have read the "operator" line the wrong way (and \
asked myself "why does he define an "operator"-function), all clear now 19:56 \
<@emostar> it kinda makes the object be a function object.. 19:57 <@emostar> and the \
LicqCallbackBase is used to put the callback objects in an STL container 19:57 \
<@emostar> std::list<LicqCallback> doesnt work because its a template 19:58 < QnD> \
yeah! 19:58 <@emostar> so if you make all of them have a common base, you can put the \
pointer  tothe LicqCallbackBase in a STL container 19:59 < QnD> yes, sure ... 
19:59 <@emostar> that or a boost::shared_ptr would do the trick
20:00 <@emostar> and like we talked about last week.. i made a class (CEventData) \
that will allow the params to be taken out by a string name.. and support any object \
(nearly) 20:00 <@emostar> http://wiki.licq.org/ProtocolEvent has the details
20:01 < QnD> okay ... looks good.  another question: how do you give the constructor \
of LicqCallback the callback function?  20:01 < QnD> yes, already saw that - exactly \
what I meant 20:02 <@emostar> like the example...
20:02 <@emostar> LicqCallback *pObject = new \
LicqCallback<CClass>("user-status-change", this, CClass::handleStatusChange); 20:02 \
<@emostar> the function we are giving is CClass::handleStatusChange() 20:02 \
<@emostar> technically CClass::handleStatusChange(void *) 20:02 < QnD> yes, but as I \
wrote above I thought that only static member functions can be used as a pointer ... \
20:03 <@emostar> nope, any function can be used as a pointer 20:03 <@emostar> because \
it isnt static, we pass the class pointer to the constructor as well 20:04 <@emostar> \
in the operator() part it does object->*function() 20:04 <@emostar> we pass both \
object and function in the constructor 20:05 < QnD> alright ... (you see: neber hat \
the time to learn much about C++). ah, I see now 20:06 <@emostar> hmm might be good \
to pick up a book ;) i'd like to see most of the work done using STL.. since that \
makes things so much easier and will save us time 20:06 <@emostar> and not to mention \
that it makes more efficient code 20:06 < QnD> yes, bought a book about C++ ;)
20:07 <@emostar> whos the author?
20:07 < QnD> Stroustrup
20:07 <@emostar> The C++ Programming Language?
20:07 < QnD> hmyes
20:08 <@emostar> ahh, i have that one too.. its very good for STL
20:08 <@emostar> rather dry.. but its the best book out there i believe
20:08 < QnD> yes, and expensive :)
20:08 <@emostar> the only thign i regret is i left that book in america... will bring \
it back the next time i go home 20:08 <@emostar> i have my assembly book with me \
though :\ 20:09 < QnD> yes, seems to be a good reference book.
20:10 <@emostar> http://books.google.com/books?id=n9VEG2Gp5pkC&pg=PA2&lpg=PA2&printsec \
=8&ots=Rci8jmccXR&dq=The+C%2B%2B+Standard+Library&sig=vYOyCr1Gzn2uhkn3pNOBf0lEfTk \
20:10 <@emostar> thats the stl "bible" 20:10 <@emostar> anyways..
20:11 <@emostar> i'd like to think we have some solid structures that are quite \
flexible.. but only time will tell when we write code with them :) 20:11 <@emostar> \
if you saw my latest commit in the newapi branch.. all plugins (not protocol though) \
will derive from this class 20:12 < QnD> $64.99 for this book - what a world .... 
20:12 < QnD> havn't had time to have a look into the new branch yet
20:13 <@emostar> only one new file.. include/licq_generalplugin.h
20:13 <@emostar> and yes.. these books are expensive..
20:13 <@emostar> even more so if you dont live in america
20:15 -!- Rapp [n=schmitz@brundtland.informatik.RWTH-Aachen.DE] has joined #licq
20:15 <@emostar> you are on the licq-cvs mailling list, right?
20:16 < Rapp> hi
20:16 <@emostar> hello
20:16 <@emostar> Rapp: i got your ssh key.. but i forgot, i will also need your \
sf.net user name 20:16 < QnD> no, just on licq-devel
20:16 < Rapp> oh, i have to look that one up...
20:17 <@emostar> QnD: well, if you are going to participate on the latest \
development.. the licq-cvs mailing list is critical.. 20:19 < QnD> hm, always thought \
licq-DEVEL is for development :) 20:20 < QnD> however, will join it now
20:20 <@emostar> well it is for development, but licq-cvs has the latest code \
changes.. which don't necessarily get discussed on licq-devel 20:21 < QnD> good \
argument 20:21 <@emostar> i use an svn mailing list at work.. even though the other \
people on the list are within talking range.. just makes it easier for everyone to \
see a diff and review that or peruse it 20:23 < QnD> yes ...
20:24 < QnD> just took a look at generalplugin.h - this should really be everything \
that's needed ... 20:24 <@emostar> yeah, i was hoping so.. not that much different \
from the current method.. just making it C++ 20:24 < QnD> (except a thing like a \
plugin description) 20:25 <@emostar> yeah... not sure if we really need that or what
20:26 <@emostar> but i have no issue with adding it if there is a good reason..
20:26 <@emostar> perhaps its better to have it.. so a descriptoin can be shown before \
the user loads it or something 20:27 < QnD> yes ... although this requires loading \
(not running) of all plugins 20:28 < QnD> (a description is quite important, because \
plugins can now be much more specific) 20:28 <@emostar> yeah.. but if the user has \
the plugin "installed" then it may not be unreasonable to load it for some \
information 20:28 < QnD> right
20:28 <@emostar> so i will add that
20:30 < QnD> another thing: I thought about plugin dependencies (here we go \
shake-window-plugin): a shake-window plugin cannot be loaded without the msn plugin \
being installed ... 20:30 <@emostar> hmm yes.. that should be done at the beginning \
of plugin initialization 20:30 <@emostar> that way it can quickly escape if it is not \
present 20:31 < QnD> and should also be another peace of information the plugin gives \
to the daemon 20:31 < QnD> (before loading)
20:31 <@emostar> hmmm.. it can be done without the daemon handling it i believe
20:32 <@emostar> what i think is best...
20:32 <@emostar> the daemon allows the plugin to see what plugins are loaded.. so \
when it is initialized it can check for that plugin's presence 20:32 <@emostar> if it \
is not there, throw an exception so the daemon knows it is missing a required plugin \
and can provide the feedback to the user 20:32 < QnD> hm, but this will require \
things like checking, giving an error message ... which must be done by every plugin \
by itself 20:33 < QnD> ah
20:34 <@emostar> if (!pDaemon->isLoaded("msn")) throw MissingPlugin("msn");
20:34 <@emostar> actually it can past a list to the daemono for it to check..
20:34 <@emostar> i just dont think that it will be used so much
20:35 < QnD> hm, my idea was just to provide a kind of string array to the daemon \
that lists the required plugins. if the required plugins are not there they could \
either be loaded or an error message could be thrown 20:35 <@emostar> hmm with the \
plugins of plugins idea.. it may be used a lot 20:35 < QnD> yes
20:36 <@emostar> so yeah.. putting that in the daemon would be nice.. and it can also \
be displayed in the plugin info before it is loaded..  so the user knows what the \
requirements are 20:36 < QnD> yes
20:36 <@emostar> i will add that as well
20:37 < QnD> another thing: do you already have plans how the info-struct of a user \
should look like? 20:38 <@emostar> havent gotten to that point yet
20:38 < QnD> ah, okay ... 
20:39 <@emostar> have you given it any thought?
20:40 < QnD> hm, that's everything I wanted to talk about for today :)
20:40 <@emostar> hmm works out well so that i can take the train i wanted to then ;)
20:40 <@emostar> just one more thing
20:41 <@emostar> if you are gonna have svn access, i need a public ssh key and your \
SF.net username 20:41 < QnD> no, not really - thought about string accessors again, \
but this might not be a good idea concerning performance 20:41 < QnD> ah, yes ... \
wait 20:41 <@emostar> yeah, i was thinking the same thing...
20:42 <@emostar> we can have a ton of functions like now (and a huge vtable)
20:42 <@emostar> or somethign like CEventData
20:43 <@emostar> perhaps CEventData isn't that big of a performance hit.. i will do \
some work later to check into this 20:44 < QnD> the most important thing is how to \
group the information later. it would be great to have some kind of info window that \
can cope with every information a proto plugin could provide ... 20:45 <@emostar> yes \
that would be nice 20:45 <@emostar> especially since ICQ has the largest info window \
of any protocol 20:45 < Rapp> maybe some sort of tree structure would make sense?
20:46 < Rapp> for grouping the information?
20:46 <@emostar> hmm.. i will have to give it some consideration
20:46 < QnD> also thought about that - but maybe this was not the best idea because \
information may be grouped in a different way to provide a good look and "lucidity" \
20:47 < Rapp> yeah... 20:47 < Rapp> depends on how "general" we want to be
20:47 < Rapp> a 1:1 mapping for every possible protocol would be quite hard, if you \
had a fixed layout like now 20:48 < QnD> yes ... but these questions will probably be \
answered as soon as there's a concrete way of how to do the GZUI things 20:48 \
<@emostar> maybe some kind of heirarchy would be best.. to help display it 20:48 < \
QnD> GZUI = GUI 20:48 < QnD> what do you mean?
20:48 <@emostar> like a General -> Name
20:49 <@emostar> Work -> Company Name
20:49 <@emostar> then the gui knows to show all the General items together
20:49 <@emostar> and the Work is a different grouping
20:49 < QnD> hm... yes
20:50 <@emostar> im sorry, but i have to get going
20:50 < QnD> but still this information cannot be just shown one after the other
20:50 < Rapp> yes, that is actually a tree :) you could do it as tabs or as a tree \
view 20:50 < Rapp> ok, cu
20:50 < QnD> yes, no problem - see you later
20:50 < Rapp> gotta get back to work, too :)
20:50 <@emostar> alright, i will leave the log running if anyone else joins in ;)
20:50 <@emostar> and will post it after i have dinner with my gf
20:51 < QnD> okay, Bon appétit!
20:51 <@emostar> thanks :) talk with you later.. email me your ssh key and sf.net \
info! 20:51 < QnD> okay :)
20:52 <@emostar> ok.. see ya
20:52 < QnD> yep
20:53 -!- BDick [n=Bernhard@p508C15DC.dip0.t-ipconnect.de] has joined #licq
20:58 <@Agrajag-> ahh crap
20:58 <@Agrajag-> i got the time wrong
20:58 <@Agrajag-> bugger it
21:05 < Rapp> lol
21:06 <@Agrajag-> heh
21:06 <@Agrajag-> well i read up and i checked out the wiki stuff this morning, it's \
all looking good 21:12 <@Agrajag-> well i got my brother who uses gaim to check out \
how it does user info GUI stuff. it just gets the protocol plugin to give back an \
html string which it displays in one big area. it's simple i guess, but less than \
ideal for displaying the information nicely (and the plugins have to do more work) \
21:15 < Rapp> yup, that's why i think some form of tree would be great. like some \
simple pointered struct or an XML string. that can be displayed as tabs or also as a \
tree widget or something else. 21:16 <@Agrajag-> yeah, that sounds good. an xml \
string describing (i guess similar to gtk's glade) the tabs/info would be cool 21:17 \
<@Agrajag-> and it wouldn't have to be too complicated because i don't imagine there \
would be the need for many different types of widgets 21:17 < Rapp> no, it could be \
simple 21:18 < Rapp> only types needed are string and maybe picture
21:18 < Rapp> the nested XML tags would give the natural hierarchy.
21:19 <@Agrajag-> yeah.. looking the icq info now there's also a tree thing in More \
II 21:19 < Rapp> if one thinks that XML is too bloated, of course everything could be \
mapped to some struct with pointers 21:19 < Rapp> right
21:21 <@Agrajag-> it would also need to be generic enough that it can be displayed \
with any gui, be it qt/gtk/ncurses 21:21 < Rapp> that is not a problem i think
21:21 < Rapp> i can write you a small XML treeview thingy :)
21:21 < Rapp> for console
21:22 < Rapp> we even do not need a full blown XML parser
21:22 < Rapp> we really only need very simple and specialized tags
21:23 <@Agrajag-> yeah.. but i think we'd want it to be extendible to an extent, so \
that if one day some other plugin comes along that wants to display something else, \
it would be simple enough to add 21:23 < Rapp> yes of course
21:23 < Rapp> but i think an XML example for our case would look like:
21:24 < Rapp> <Userinfo><category name=?General?><text label=?Alias? value=?John Doe? \
/>...</category>....</Userinfo> 21:24 < Rapp> you will not need much more
21:25 < Rapp> instead of <text> you could also use a <picture> tag
21:25 <@Agrajag-> yep
21:25 < Rapp> i cannot think of much more that one could need
21:59 -!- QnD [n=QnD@p54B3A433.dip0.t-ipconnect.de] has quit [Remote closed the \
                connection]
--- Log closed Thu Apr 26 22:00:39 2006


[Attachment #6 (application/pgp-signature)]
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Licq-devel mailing list
Licq-devel@licq.org
https://lists.sourceforge.net/lists/listinfo/licq-devel

[prev in list] [next in list] [prev in thread] [next in thread]