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

List:       licq-devel
Subject:    [Licq-devel] Licq Meeting 2006-04-19 (#3)
From:       Jon Keating <jon () licq ! org>
Date:       2006-04-19 13:51:37
Message-ID: 20060419135136.GA2491 () licq ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


Once again we had our weekly meeting, it was our 3rd one and we are
starting to get more people to come and participate in the discussions.
Here is a summary of what was discussed:

  * Handling of responsibilities
    * Rapp will be taking care of the mailing lists
    * rsLeo will help with maintaining and improving the website
    * Agrajag and Rapp will help test/review patches
    * Agrajag will be the new release engineer
    * Rapp will assist with the German translation if Thomas (both?)
      are unable to.
  
  * The new Licq API will use parts of the Boost library
    (www.boost.org) for implementing details. I'd also like to see more
    usage of the STL. There are many good books out there about C++/STL
    and designing with these. Look for books by Herb Stutter and Scott
    Meyers if you are interested (of course Bjarne Stroustrup's book is
    good too ;)

  * More details of the new API were discussed
    * Sending events to users will be done by a function in the user's
      class
    * How to handle multiple accounts on the same protocol
      simultaneously
    * Plugins of plugins was mentioned (i.e. for video chat)

In 2 weeks, I won't be available for the meeting on Wednesday. If you
guys want to have it late on Tuesday, that would be better for me.
Wednesday - Sunday will be my holiday (Golden Week in Japan), so I
might not be around much. I will probably be going on a short trip
somewhere.

That's all for now.

Jon

-- 
________________________________________________________
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-20060419" (text/plain)]

--- Log opened Wed Apr 19 20:04:49 2006
20:05 <@emostar> So, let's start, ok?
20:05 < Rapp> ok
20:05 <@Agrajag-> yep
20:05 < QnD> yup
20:05 <@emostar> I added some more information to the Wiki, not a whole lot, but have \
more to discuss. 20:06 <@emostar> As for the protocol event structure, like QnD said \
on the mailing list, an interface that provides a generic interface to set/get data \
should be implemented. 20:07 <@emostar> I have been playing around with a few \
different implementations and thought perhaps using the Boost library would be nice. \
It has a lot of code that could come in handy. 20:07 < Rapp> like what in particular?
20:07 < QnD> Boost library ... what is it for?
20:07 <@emostar> smart_ptr in particular
20:08 <@emostar> its a collection of libraries.. some of which will probably make \
their way into standard C++ 20:08 < Rapp> QnD, www.boost.org
20:08 <@emostar> they have some libraries that deal with generic templates
20:08 < Rapp> hm, ok. smart_ptr is a nice thing.
20:08 < QnD> never heard :)
20:08 <@emostar> let me show some example code...
20:09 < Rapp> they actually have a whole lot of support classes, for almost \
everything... 20:09 <@emostar> http://licq.pastebin.com/668973
20:10 <@emostar> yes, i find them very useful. the only thing i would be worried \
about is how hard is it to distribute them with licq, so people don't have to go and \
download the boost libraries to compile licq. 20:10 < QnD> what in your paste was \
boost-code now? everything? 20:10 < Rapp> QnD, the shared_ptr
20:10 <@emostar> shared_ptr is Boost code
20:11 < Rapp> emostar, boost is part of every major distro now...
20:11 < QnD> and what does it do?
20:11 < Rapp> i don't think it would be a very hard limitation
20:11 <@emostar> CEventData is a template... so you cannot have it in an STL \
container (the way we want at least) 20:11 < Rapp> QnD, keeps track of who still \
references the pointer 20:11 <@emostar> so you have 2 options, create a base class \
that does nothing and make a list of that 20:11 <@emostar> or use share_ptr
20:11 < QnD> nice
20:12 <@emostar> also does memory deallocation on its own
20:12 <@emostar> similiar to std::auto_ptr
20:12 < QnD> nicer
20:12 <@Agrajag-> sounds good
20:12 < Rapp> http://www.boost.org/libs/smart_ptr/shared_ptr.htm
20:12 < Rapp> better than auto_ptr actually. the latter cannot be shared
20:12 <@emostar> Rapp: hmm dont think it is in my distro...
20:12 < Rapp> really?
20:12 < Rapp> what do you use?
20:13 < Rapp> opensuse and debian contain it
20:13 <@emostar> Slackware 10.0
20:13 < Rapp> ok :)
20:13 < Rapp> but people with slackware know how to install it :)
20:13 <@emostar> and its in fedora..
20:14 <@emostar> i believe it can be bundled with licq.. there isnt anything to \
really compile (3 libs??). most of the work is in the header files. 20:14 < Rapp> \
thats true 20:14 < Rapp> but one problem is always: having the most recent \
versions... 20:14 <@Agrajag-> but then i guess you'd want to keep that up to date \
with boost 20:14 < agliv5> This might be a stupid question, but I'm new to Linux so \
here it goes: Can PC games that are designed for windows be run under Linux? 20:14 \
<@emostar> if we Boost, then http://wiki.licq.org/?title=LicqCallback should use \
shared_ptr instead of the base class that does nothing. 20:14 <@Agrajag-> agliv5: \
this isn't the place to ask that 20:15 < agliv5> I know
20:15 < Rapp> agliv5, look up cadega and wine. and ask on another channel :)
20:15 < QnD> hm, boost seems to be cool, but I still don't understand why we need \
this 20:15 < Rapp> QnD, helps with the development
20:15 < Rapp> higher level code -> easier maintenance
20:15 <@emostar> QnD: it provides code that we will implement.. so theoretically \
things are faster if we have the code in a library already ;) 20:15 < Rapp> since \
emostar is doing most of it it would be great for other people to step in :) 20:16 < \
QnD> hm, however - will propably understand it later ;) 20:16 <@Agrajag-> if you \
think we're only going to use a small part of it then i guess it's ok bundling it \
20:16 <@emostar> QnD: function - Function object wrappers for deferred calls or \
callbacks, 20:16 <@emostar> it has that.. not sure if we really need it though.
20:17 <@Agrajag-> were there any other libraries/frameworks/whatever that you came \
across? 20:17 < Rapp> so, is there -- apart from boos -- a top plan for today? what \
has to be clarified? 20:17 <@emostar> Agrajag-: not really..
20:17 < Rapp> s/boos/boost
20:18 < rsLeo> work sharing
20:18 <@emostar> Rapp: yes, seeing about getting some responsiblities to other people
20:18 < Rapp> ok. what tasks do have to distributed?
20:19 <@emostar> Mailing list admin... Release engineer (releases arent often so \
should be easy).. Web site improvements/maintenace.. Reviewing patches.. 20:20 \
<@Agrajag-> i'm the release engineer at work (and we use svn) so i'll be happy to do \
that :) 20:20 < Rapp> i read on the wiki thomas reitelbach isn't active anymore? do \
we still have someone watching the german i18n? 20:20 <@emostar> thomas is busy with \
other things... he told me he'd still like to help out with the german translation \
though 20:20 < Rapp> mailing list admin -- i could do that, i guess? what's the job?
20:20 <@Agrajag-> i'll be happy to review patches for parts of licq that i understand
20:21 <@emostar> Agrajag-: I'll get some documentation about how i have been doing \
the releases into the wiki soon 20:21 < Rapp> emostar, otherwise i could do the \
german translation. 20:21 < QnD> what about general development?
20:21 <@emostar> incoming paste......
20:21 <@emostar> Message from DreamForce
20:21 <@emostar> Sat Feb 18 19:07:44 2006 [----]
20:21 <@emostar> anyway, from time to time i would like to update the german \
translation since licq still is my favorite client and _when_ i use ICQ, then it's \
licq ?? 20:21 <@emostar> Message from DreamForce
20:21 <@emostar> Sat Feb 18 19:06:49 2006 [----]
20:21 <@emostar> as you know, i'm no longer active with licq anymore. i've become the \
project leader of the german i18n KDE team and this takes most of my free time. 20:21 \
<@emostar> Rapp: mailing list admin is just checking the queue and deleting spam and \
allowing messages though 20:22 < Rapp> well, i guess i could do that :)
20:22 <@emostar> i do that when i get around to it.. but sometimes valid messages get \
held off for a month :\ 20:22 <@Agrajag-> if more than one person is needed i'll help \
with that too 20:22 <@emostar> Rapp: I'll give you the URLs and passwords after i \
setup your account. i just need your e-mail address 20:22 <@emostar> Agrajag-: sure, \
the more the merrier ;) 20:23 <@emostar> phone.. brb
20:23 < rsLeo> I could do website improvements
20:23  * Rapp has icq # 49247365 -- would be nice to be able to talk to you all :)
20:24 < agliv5> emostar how'd you end up being the project leader of a german team?
20:24 < Rapp> agliv5, no, not he...
20:24 <@Agrajag-> emostar: that's not him that's DreamForce
20:24 < Rapp> thomas is
20:24 <@Agrajag-> err
20:24 < QnD> ... but these are the smaller tasks. I hoped to see a list concerning \
some more important stuff 20:24 <@Agrajag-> agliv5 rather
20:24 <@emostar> just a min
20:27 <@emostar> rsLeo: i'll give the info to you when i get the server finished
20:27 < rsLeo> ok
20:28 <@emostar> Agrajag-: ahhh... yes
20:32 < QnD> hm ... still on the phone :)?
20:32 <@emostar> yes......
20:33 < agliv5> I know this isn't really the right forum, but nobody else is \
answering me... I can log in as su, but sudo for example doesn't work... I get a \
password incorrect error... what's up with that? 20:33 <@Agrajag-> agliv5: join \
#ubuntu 20:34 < agliv5> I am in Ubuntu
20:34 < Rapp> agliv5, no, join the channel #ubuntu -- type /join #ubuntu in your irc \
client 20:34 < Rapp> please!! :)
20:34 < agliv5> I've been asking questions all morning and I haven't goten a single \
reply 20:34 <@emostar> back
20:34 < QnD> for doing sudo you need to type in the users password and not your root \
password 20:35 <@Agrajag-> agliv5: perhaps because you're asking questions that are \
well documented and could be solved with a simple google search 20:35 < agliv5> Of \
course I know that THIS forum is Licq 20:35 < Rapp> back to business
20:35 <@emostar> yes
20:36 <@emostar> so if we could get some people to work on patches, the main thing is \
testing that it works and doesn't break anything 20:36 <@emostar> and if it works, \
just send a note to the email list that it worked or what problems there were 20:37 < \
agliv5> Agrajag- I aggree that 99% of the questions that I asked today were solved by \
google, but what am I supposed to search for whith authentication problems? 20:38 < \
Rapp> hm, ok. i could do that, but my time is a bit limited, sadly. i also got some \
ideas for small patches that annoy me and some friends of mine. but diving into the \
licq code is the biggest problem.... 20:38 <@emostar> agliv5: please hold on to the \
questions for later.. we only get  to meet once a week, so we have to stay focused \
20:38 <@Agrajag-> emostar: ok, so what sort of patches are we talking about here? \
changes to the api? updating existing plugins to work with the new api? 20:38 < \
agliv5> oh I'm sorry I didn't know I was inturupting SORRY 20:39 <@emostar> agliv5: \
no worries.. we'll be done in an hour i believe 20:39 <@emostar> just generic patches \
sent by other people 20:39 <@Agrajag-> ah right ok
20:40 <@emostar> they are usually small and easy to test... but its nice to have \
other people help out cuz sometimes i get many small patches in the queue that takes \
a long time 20:40 <@emostar> so, perhaps we can talk about the API now?
20:40 < QnD> YES!
20:40 <@emostar> hehe ;)
20:40 <@Agrajag-> hehe yep
20:41 <@Agrajag-> brb
20:41 <@emostar> there is one major point that i haven't addressed yet in the wiki or \
in my own documents that i scribble.. 20:41 -!- sgt-d \
[n=sgt-d@24-107-46-25.dhcp.stls.mo.charter.com] has quit ["mIRC Power Pack 8.00 \
(www.mIRCPowerPack.com) by sod/sgt-d (sgt-d@sodpit.com)"] 20:41 <@emostar> another \
main advantage of redoing the API is to allow multiple accounts for the same protocol \
20:42 < QnD> sure 20:42 <@emostar> at a lowlevel, it means the protocol will have to \
have more than one instance running.. 20:44 <@emostar> at a higher level.. the API \
has to specify with instance to use 20:44 < QnD> if the protocol was an object this \
wouldn't be THAT problem, I think. Something like you wrote in your wiki \
"daemon->pushToProto(u->getPPID(), "send-message", pMsgData);" would be not ideal \
then, better is "daemon->pushToProto(u->getProtocol() "send-message", pMsgData);" \
(where getProtocol() gets the address of the protocol object) 20:44 < Rapp> will the \
protocol plugins still be realized through .so files? or will they be just statically \
linked to the daemon? 20:44 <@emostar> Rapp: .so files
20:45 <@emostar> QnD: well the main issue is if i have the same user on 2 accounts.
20:45 < QnD> i don't know how hard it is in a lowlevel way to make out which pakets \
come from which user of the same proto 20:45 < Rapp> QnD, i guess they will arrive on \
different ports? 20:45 <@emostar> at the low level (in the daemon) it has to match \
the user to the protocol instance. the common denominator is the account owner. 20:46 \
< Rapp> ah, that way around, ok 20:46 < QnD> ah, okay. so every instance of a proto \
object would receive everything and then decide whether it drops the packet (wrong \
account) or not ... 20:46 <@emostar> a user object will have to be aware of its \
owner.. 20:47 <@emostar> QnD: the daemon's job is to make sure it goes to the correct \
place 20:47 <@emostar> putting that work in the protocol plugin makes it complex for \
the protocol plugind evelopers 20:47 < QnD> yes, but to do this the deamon already \
has to understand icq packets for example. and this is not his task 20:47 <@emostar> \
the daemon needs to ensure everything goes where it is intended to go, in the correct \
order 20:48 <@emostar> well, the daemon doesnt know about icq packets.. its just \
pushing signals/events around 20:48 < Rapp> oh, i see
20:48 <@emostar> inside the signal/event needs to be something to tie it with the \
correct plugin instance 20:48 < Rapp> sounds clever
20:48 < Rapp> the daemon is only some sort of switch routing the signals around
20:49 <@emostar> yes.. and as we discussed before, the daemon wont even know what it \
is pushing around exactly.. it just obeys the rules it has.. 20:49 < Rapp> icq \
packets will only be dealt with in the icq protocol plugin, right? 20:49 <@emostar> \
yes 20:49 < Rapp> yeah
20:49 < Rapp> cool
20:49 < Rapp> sounds good
20:50 < Rapp> maybe you should put a drawing in the wiki? :)
20:50 < QnD> hm, havn't got that right ... what if there is a proto plugin now and it \
is sending packets to the icq server. another proto plugin also does this and now two \
packets come back. how will the proto plugin know which packet is for which instance? \
20:50 < Rapp> QnD, they will be received on different ports 20:50 < Rapp> and each \
proto plugin listens on a different port 20:50 <@emostar> the socket descriptor is \
unique for each protocol plugin 20:51 < QnD> i don't have much experience with the \
core of the icq proto, but I've always thought it's always on 5190 20:51 < Rapp> QnD, \
on the server side, yes 20:51 <@emostar> thats the remote port ;)
20:51 < QnD> aaaahh, okay :)
20:51 < Rapp> QnD, read up on basic network programming :)
20:51 <@emostar> on the local side, we just listen to the descriptor that is \
connected to the server 20:51 <@emostar> its nothing different than what licq does \
now if there is an icq and msn account both online 20:51 < QnD> Rapp: might be a good \
idea 20:51 < Rapp> and that will be some random port number
20:52 <@emostar> but for example.. if ICQ#1 and ICQ#2 is online.. the plugin will \
tell ICQ#2 to go away 20:52 <@emostar> so the daemon needs to send the \
"status-change" signal only to ICQ#2 20:52 < Rapp> great, so emostar, you basically \
have to do a detailed sketch of the API, the functions and their semantics, and then \
everyone can implement some of the functionality :) your ideas sound simple enough... \
:)) 20:53 < QnD> why should it tell this to ICQ#2?
20:53 <@emostar> Rapp: yeah.. the only hard put is putting it all together to a \
complete whole. currently im slowly piecing it together.. then will put the final \
glue together when all the small parts are ready 20:54 <@emostar> for example.. the \
qt-gui has an icq status flower for each instance 20:54 < Rapp> ok
20:54 <@emostar> the user tells one account to change status
20:54 < QnD> yep
20:54 <@emostar> currently it is done by specifying the protocol id...
20:54 <@emostar> but if we support multiple accouns with the same protocol.. it needs \
more than a protocol id 20:54 <@emostar> it needs an id for that instance
20:54 < Rapp> actually, we could even use the Qt signal/slot scheme for this...
20:55 <@Agrajag-> Rapp: no i don't think so
20:55 < Rapp> and the daemon could connect() the parts?
20:55 < Rapp> ok, why not?
20:55 < QnD> that's what I meant above. don't use the protocol ID as an argument but \
the proto object itself 20:55 <@Agrajag-> Rapp: other plugins shouldn't need qt \
dependancies 20:55 <@emostar> Rapp: techinally.. thats what we are doing
20:55 < Rapp> that's true
20:55 <@emostar> Rapp: that part is mentioned in the wiki.. and in the previous 2 \
meeting logs ;) 20:55  * Rapp blushes
20:55 < Rapp> oops
20:56 < rsLeo> why should a person login to one protocol with different account at \
the same time? 20:56 <@emostar> QnD: the protocol ID? hmm.. that works with sending \
events like "logon" "change-status" .. etc 20:56 <@emostar> but "send-message" will \
need more i believe 20:56 < Rapp> rsLeo, because one for spam, one regular. one for \
the wife, one for the spouse... :) 20:56 < Rapp> doing it that way is also more \
general, and thus much simpler. 20:56 < Rapp> since it is not harder to implement
20:57 < rsLeo> ok
20:57 <@emostar> rsLeo: you can then send test messages to yourself to debug your new \
features ;) 20:57 < Rapp> lol
20:57 < QnD> at the moment I cannot imagine why ... with the proto obj address \
everything is given the daemon could need -> the protocol instance. 20:58 < rsLeo> \
emostar: for testing i can use -b at the moment and start multiple instances. 20:58 \
-!- erijo [n=metallma@h154n2fls34o840.telia.com] has joined #licq 20:58 <@emostar> \
hmm.. just seems like a bit of a burden on the plugins to maintain the object id for \
everything.. 20:58 <@emostar> rsLeo: yeah.. but you can do it in the same instance.. \
just was joking anywyas 20:59 <@emostar> when it sends a message, it needs to object \
id then... 21:00 < QnD> don't see a burden here ... when you want to do something \
with a user (eg sending him a message) you always have his proto 21:00 <@emostar> i \
was thinking that a user would have an owner.. and then the daemon can map the owner \
to the protocol instance 21:01 <@emostar> but one protocol can have 2 instances..
21:01 < rsLeo> why not using the socket id to identify a protocol/user
21:02 <@emostar> the user object needs to have some reference to the protocol \
instance..... 21:03 < QnD> I don't think that's very obvious. generally I don't \
really understand why for example "sendEvent" is a function of the daemon and not of \
a user (which then passes the event to the daemon) 21:03 <@emostar> that way the \
plugins can just do: pushToProto(pUser, "send-msg", pData); or something similiar. \
21:04 <@emostar> QnD: hmm interesting idea 21:04 <@emostar> perhaps that is easiest \
for the plugins 21:05 <@emostar> the daemon will do the push event to the protocol.. \
so the plugin just calls send message.. 21:05 <@emostar> ahh
21:05 <@emostar> the reason we dont do that is because the daemon doesnt know what a \
message is technically 21:06 < QnD> in the end the thing that is done concerns the \
user and not the daemon, so it should be a user function. Something like \
LicqUser->SendEvent("name", variables);. This function then calls the daemon with the \
right plugin instance as a parameter (or the socket descriptor, however - although I \
think using the socket descriptor as a parameter would break a good \
abstraction-leveled system) 21:07 <@emostar> user->sendEvent("send-message", pData); \
should be sufficient 21:07 <@emostar> like you said ;)
21:07 < QnD> yeah ;)
21:08 <@emostar> giving the plugin a socket descriptor is asking for trouble \
close(sockFD); 21:09 < QnD> what do you mean with that?
21:10 <@emostar> the plugin can disconnect protocol plugins if we give it a socket \
descriptor.. 21:10 <@emostar> but anyways..
21:11 < QnD> also using an ID which is not the proto instance address would require a \
list in the daemon that can allocate the ID to the instance... 21:12 < agliv5> Are \
you all still in a meeting?  I promise it's a Licq question :) 21:12 < QnD> (the list \
of loaded instances should be there anyway but there's no need to do an ID-comparison \
to find the right proto instance 21:12 < rsLeo> agliv5: yes still in meeting
21:13 <@emostar> yeah.. will have to work on some implementations... perhaps you can \
write something up in the wiki while im still working on the main api? 21:13 \
<@emostar> agliv5: you can ask if its about licq.. just dont expect an immediate \
reply 21:13 < QnD> yes
21:14 < QnD> another thing I wanted to talk about is a common abstract protocol \
interface 21:14 < agliv5> Can I install using Slackware's installation guide or is \
the guide to old?  Is there a more up-to-date guide somewhere? 21:15 <@emostar> QnD: \
alright.. go ahead 21:15 < QnD> i don't know much about the core stuff  of protocols \
but it would be cool if there was a common interface which every protocol plugin \
supports 21:15 <@emostar> agliv5: its old.. but may still work, not much has changed
21:16 < agliv5> Oh yeah, and the link to the unofficial Licq manual is dead
21:16 < agliv5> emostar thanks I'll do my best
21:16  * Rapp is back. sorry... had to work....
21:16 < QnD> something very basic like sendPacket(&packetData); 
21:16 <@emostar> QnD: that can be done... having a base plugin implement some of the \
basic functions and then the base plugin connects the callbacks to the daemon 21:16 < \
QnD> or something 21:17 <@emostar> hmm yes..  we do have licq_socket.h
21:17 < QnD> the purpose of this simple API should be the possibility to extend it by \
other plugins - and here comes the all beloved "shake window" example again 21:19 < \
QnD> a "shake window"-plugin then could look for the existence of the MSN plugin (if \
its not there it just stops). if it IS there it tries to get the exported lowlevel \
functions, something like daemon->getPlugins("MSN"); and then \
plugin1->sendPacket(&shakewindowPacket); 21:20 <@emostar> it will also need to be \
able to connect callbacks to the daemon.. 21:21 < QnD> yes, of course ... it's a \
normal plugin that can also add "services" 21:22 < QnD> it adds the service "shake \
window" where the main window (which is maybe also influenced by this plugin) then \
listens to 21:22 < QnD> main window -> message window
21:22 < QnD> not "main window"
21:23 <@emostar> we could do all that.... but is it necessary to add the overhead of \
plugins of plugins when it can just be in the plugin? 21:24 < QnD> sure, but I'm \
thinking of things like video chat which are (probably) complicated enough for an own \
plugin ... 21:24 <@emostar> hmmm yeah
21:24 < QnD> or "push to talk" or "icq games" or things like that. things that might \
not be wanted by everybody. whoever likes the features can add them by plugins 21:25 \
< QnD> (this kind of plugins then are probably "hybrid" plugins which serve GUI AND \
protocol stuff) 21:26 <@emostar> yes, this will need some design work done too if we \
are to implement it 21:26 <@emostar> i was thinking that too actually
21:27 < QnD> hm yes... I have some concrete ideas but havn't articulated them yet - \
will do this and post a message in licq-devel 21:28 <@emostar> sounds good
21:29 < agliv5> Do I need to use qt 2.0.2 as the guide instructs or should I use a \
newer version? 21:29 <@emostar> agliv5: take a look at the website, it has the \
requirements (qt 3.0 or higher) 21:30 < QnD> there are also other things I was \
thinking about GUI stuff but this is still too far away. just wanted to throw my 5ct \
in the round before I have to go (which is now) 21:30 < QnD> see you next week
21:30 <@emostar> alright, well you can always add it to the wiki or send a mail..
21:30 <@emostar> ok, talk with you later
21:31 < QnD> great - have a nice evening
21:31 -!- QnD [n=QnD@p54B39925.dip0.t-ipconnect.de] has quit ["... und tschüß"]
21:34 <@emostar> anyone around?
21:34 < erijo> emostar: Have you considered making the daemon a separate process and \
making it possible to connect to it with more than one "gui" at the same time?  21:35 \
<@emostar> erijo: thats what the new api would allow 21:35 < erijo> ahh great
21:36 <@emostar> there is some basic support for it now.. but it wasnt done that way \
by design 21:36 <@emostar> so it doesnt work perfectly..
21:36 <@emostar> but the new api is being designed to support plugins in the correct \
manner.. 21:37 < erijo> this would mean it's possible to have the daemon on a server \
and connect to it remotely over tcp/ip, or? 21:37 <@emostar> hmm.. no..
21:38 <@emostar> if thats what you want.. even with the current api it can be done \
that way if someone writes an interface for the rms plugin 21:38 <@emostar> i think 4 \
years ago i made a basic win32 interface for the rms plugin 21:39 <@emostar> never \
released it.. and it got lost.. but it really was basic 21:40 < erijo> ok. I might \
have to take a look at it when the development of the new licq is started... 21:41 < \
erijo> it would be a great feature 21:41 < Rapp> (also still here) so, when do you \
think will some final draft of the API be ready?  21:41 <@emostar> erijo: i think you \
can do the work now with the RMS plugin 21:42 <@emostar> that part of the rms plugin \
won't change... just the inner workings will change 21:42 < rsLeo> Why would \
spellchecker be a protocol plugin? 21:43 <@emostar> Rapp: good question... depends \
how much time i spend on it.. i've been reading some new C++ books i have as i go \
along to see if it can be improved 21:43 <@emostar> rsLeo: it wouldnt be..
21:44 < rsLeo> In one of your last mails you said "It's better to say protocol \
plugins (PP) and general plugins (GP). (RMS isn't a GUI and spellecheker won't be a \
GUI)." 21:45 <@emostar> yes.. a spellchecker would be a GP (General Plugin, not GUI \
plugin) 21:45 <@emostar> i was saying that GUI Plugins will be called GP (General \
Plugins) 21:45 < erijo> I most definitely will take a look at it when I get back home
21:46 < rsLeo> ok, i see
21:48 < rsLeo> i have to go. cu next week.
21:48 <@emostar> alright, thanks for coming
21:49 <@emostar> Rapp: I guess we can finish it now?
21:50 < Rapp> sure :)
21:50 < Rapp> gotta get back to work, too
--- Log closed Wed Apr 19 21:50:20 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]