Attached is the log from the IRC meeting of this week. The main points discussed were:
* The new callback system * Plugin priorities * More aspects of how the new API will be used and its goals Also, a few points I brought up that should be discussed in more detail (only rsLeo was present at this time). * Python prototype * Dividing up my responsibilities Please take a look at the log for more details and provide your opinions here and hopefully more people will be able to attend the meeting next week. If Wednesday nights aren't a good time, please let me know when is the best time for everyone that wishes to participate. 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 12 21:01:39 2006 21:01 <@emostar> lets start the meeting now 21:02 < CapnKernel> Ok. 21:02 < CapnKernel> Want to say I found reading the log of last week's meeting very interesting and helpful. 21:02 <@emostar> continuing from last week, i have spent some time working on a design of the new API, but it isnt complete. I'd like to discuss that first 21:02 < CapnKernel> All ears. 21:03 <@emostar> The one thing that I'd like to modify about last week's idea, was that you can register many signals to one callback. I think it would be a better design to have eachs signal to a different callback. that will alleviate passing some information to the plugin, that the plugin then decodes to decide what signal it is getting. 21:04 < rsLeo> I'm back from lunch. 21:04 <@emostar> rsLeo: right on time just about ;) 21:07 <@emostar> hmm hard to tell if someone is typing or waiting for me.... 21:08 < rsLeo> I think waiting. 21:08 <@emostar> well i will continue. 21:08 < CapnKernel> Yes we're listening. 21:09 <@emostar> The basic structure of callbacks that I was thinking, was having a template class that the plugin will create for each signal it wants to connect to 21:10 <@emostar> the way it works would be: 21:10 <@emostar> #1 Create a callback object passing the function to get called back 21:10 <@emostar> #2 Calling the daemon to add this callback to the queue for that specific signal 21:11 <@emostar> #3 The daemon calls the functions with the soon to be decided parameter 21:11 <@emostar> I think this idea provides some more flexibility because when the callback is assigned in the daemon, each callback can have a specific priority set.. that would be much better than setting a general priority rank for an entire plugin 21:13 <@emostar> As for the parameter, I see 2 choices: 21:13 <@emostar> #1 Pass a void * ... this is very Cish 21:13 <@emostar> #2 Pass a base class pointer that all parameters will be based on, this is more C++/OO and I prefer this better 21:14 <@emostar> Both the Plugin API and Protocol Plugin API will use these kind of system of callbacks 21:15 < CapnKernel> I'm afraid I have to go, the fan on my VGA card just stopped :-( 21:15 < rsLeo> lol 21:15 <@emostar> quick! switch your stdout to your printer 21:16 < rsLeo> You have a Plugin API and a Protocol API. If you have encryption where should that be implemented? 21:17 <@emostar> Plugin API 21:17 <@emostar> Protocol API is strictly for network protocols 21:17 -!- CapnKernel [EMAIL PROTECTED] has quit ["Leaving"] 21:17 <@emostar> The idea for an encryption plugin would be to have the highest priority for "send-message" and "recv-message" signals. 21:18 <@emostar> That way it would be the last to handle "send-message" and the first to handle "recv-message" 21:18 < rsLeo> ok 21:18 <@emostar> The new API would create a pipeline in the daemon that handles the chain of plugins processing them based on priorities. 21:18 <@Agrajag-> do the plugins define their priorities? 21:19 <@emostar> That is one of the weak points of the current API, it has no real way of modifying events. All plugins will get the same event at basically the same time 21:19 <@emostar> Yes, if they need to, they can specify a priority... otherwise the daemon will automatically assign it (based on order of loading). 21:20 <@emostar> Another idea is creating classifications of plugins that automatically have a set rule of priorities... but I don't think its too evil in letting the plugin developers assing their own for each signal. I think it gives more flexibility. 21:20 <@Agrajag-> perhaps there could be different points that the plugin could define itself to be called at 21:21 <@emostar> What exactly do you mean by different points? 21:21 <@emostar> Stages in the pipeline? 21:21 <@Agrajag-> yeah 21:21 <@Agrajag-> like a spell checker plugin would get called as the user is typing 21:21 <@emostar> Yeah, I was thinking of having an unsigned char.. so there are 256 different priority levels... 21:21 <@Agrajag-> an encryption plugin would get called when the user clicks send and such 21:22 <@emostar> Ahh, those would be handled by signals 21:22 <@Agrajag-> the only problem with that is it might not be so flexible in the future if we don't think of all the different points 21:22 <@Agrajag-> hmm right ok 21:22 <@emostar> The idea is that the signals will be very generic. Plugins can create new signals... 21:23 <@emostar> The daemon will just be a dumb relay. Pushing signals to the connected listeners. 21:23 <@Agrajag-> ah yep ok 21:23 <@emostar> For example, the "shake-window" signal I talked about last week 21:24 <@emostar> Currently, the daemon does almost all of the work. The idea is to make the daemon as simple as possible and let the plugins do the work. 21:25 <@Agrajag-> yeah, that definitely sounds like the right approach 21:25 <@emostar> The main responsibilities of the daemon would be to manage plugins, push signals around, user management, config file management... 21:26 <@emostar> Can you think of anything else? 21:28 < rsLeo> You said modifying of events is not possible? In which case would this modifiying be usefull? 21:28 <@Agrajag-> hmm not really. if the functionality is all divided up into smaller plugins i think that would be the easiest to manage 21:28 <@emostar> rsLeo: Encryption plugins have to modify the contents of the message to decode/encode. 21:29 <@emostar> Spellcheckers have to modify the text (if thats what they are designed to) or show the errors 21:30 <@emostar> Agrajag-: well the functionality would still be in the daemon. Just all protocols will be plugins (get icq out of the daemon, which it is dangerously tied to closely with). 21:32 <@Agrajag-> ok, sounds good, im just not sure how the priorities would work 21:32 < rsLeo> Aren't the priorities of the plugins in this case useful? 21:33 <@emostar> if we have 2 plugins watching the "send-message" signal, the higher priority will be called first 21:33 <@emostar> for example, a spell checker that modifies text automatically when a message is sent and an encryption plugin 21:33 <@Agrajag-> for example, you said the encryption plugin would take the highest priority. what if, for whatever reason, another plugin comes along that needs to do stuff after encryption? 21:33 <@emostar> the spell checker must run before the encryption routine 21:34 <@emostar> well, as i was thinking, there would be 256 levels. the encryption is "high" so it should be around 200 21:34 <@emostar> if something is higher, it can be at 201 21:35 <@emostar> this allows other plugin developers to find an open spot to put their plugin in so it gets run at the right time (if it is necessary) 21:35 < rsLeo> good idea 21:35 <@Agrajag-> but then if there's a plugin at 200 and at 201, and i want one inbetween, i have to get the developer of one of them to change 21:36 <@Agrajag-> (im not trying to say this isn't a good idea, im just trying to make sure there won't be problems) 21:36 < rsLeo> thats a general problem we will have if we use numbers for priorities. 21:37 <@Agrajag-> .. and i don't have a better idea :) 21:37 <@emostar> yeah.. i was worried about that.. but the actual chances of it happening are low. but they do exist, so tahts why i also though of having priority classifications. and then a lower classification within that 21:37 <@emostar> s/though/thought 21:37 <@emostar> my typing is attrocious.. as is my spelling :p 21:38 <@emostar> but i really do think the simple 256 levels would be sufficient.. if a developer has to modify a code.. then it shouldnt be that bad 21:38 < rsLeo> yes I agree 21:38 <@emostar> if the priorities are taken at a reasonable rate.. then the developers should intentionally leave some open spaces 21:39 <@emostar> i really dont think we will have 256 plugins loaded at once... 21:39 <@emostar> protocol plugins wont have priorities, naturally... 21:39 <@Agrajag-> i think it would be useful if the plugins could provide more information about what they need to do and when, so the daemon would be smarter about calling plugins 21:40 <@Agrajag-> the other problem with priorities is that you'd need to know about other plugins priorities so that you can insert yours in the right place 21:40 <@emostar> the main problem with that... is the daemon has to be aware of the diffrent types of plugins and how their priorites rank. 21:40 <@emostar> then if there is a new "type" of plugin... the daemon wont know about it 21:41 <@emostar> yeah, there will have to a list that is maintained 21:41 <@emostar> i have seen other systems use this kind of master list (actually, i think it was a microsoft api...) 21:42 <@emostar> having a system that doesnt have this kind of issue is ideal.. but im not sure how to make such a system. 21:42 <@Agrajag-> ok. i gotta go (at gf's place and dad needs to use computer, heh). i'll think more about this and get back to the mailing list 21:42 <@emostar> with the one im proposing, it should at least be managable without much difficulty. 21:42 <@Agrajag-> cya 21:42 <@emostar> alright, good night! 21:43 <@emostar> looks like the meeting is coming to a quick end..... 21:43 < rsLeo> good night 21:43 < rsLeo> yes 21:43 <@emostar> half the members are gone :o 21:43 <@emostar> so, do you have any questions or ideas, rsLeo? 21:43 < rsLeo> I think priorities has disadvantages but at the moment there's no better way. 21:44 <@emostar> yeah.. 21:45 <@emostar> its definitely doable though 21:45 < rsLeo> Making plugins modifying events could be done if the plugins return events too. 21:46 <@emostar> yes, when the callback is done it will return the event to the daemon.. which means that it may be modified 21:46 <@emostar> then the daemon takes the modified event and goes to the next plugin 21:47 < rsLeo> all right 21:47 <@emostar> on another subject... 21:48 <@emostar> the time required for this project will depend on how many people we have working on it 21:48 <@emostar> i was thinking of some ways to help work as a group, and thought maybe having a prototype in python or something might help things go faster in the longrun.. but then i thought maybe it would be a waste of time on the otherhand.. 21:50 < rsLeo> if there are people willing to help they need some help i think 21:51 <@emostar> yes.. basically a python prototype would be a form of psuedo code that actually works so you can play with the system and (ideally) identify weak spots or things that wont work out as expected. 21:51 <@emostar> if we identify the problems before the new api is halfway done it can save some time 21:52 < rsLeo> yes. the question is how complete should the prototyp be? 21:53 < rsLeo> It should be enough to implement the important interfaces and objects. 21:54 <@emostar> yeah.. i was thinking of not that complete (might be better...) but just basically pseudocod ethat can be divided and assigned parts to developers with a clear framework.. 21:54 < rsLeo> With the prototyp the plugin developers can change there code too without looking at the real code. 21:55 < rsLeo> That's a very good idea. 21:55 <@emostar> so that means we will have to decide the api function names, objects, and the objects public api 21:55 <@emostar> that would be towards the end of the prototype stage that it will be all done 21:56 <@emostar> but yeah, gives the developers a bit of a head start 21:57 < rsLeo> ok, next meeting in one week? 21:58 <@emostar> yeah, id just like to say one more thing that id like to have discussed next week 21:59 <@emostar> dividing some of my responsibilites up to other people... right now im still doing nearly 100% of all work (minus patches, but i review patches and modify them) 22:00 <@emostar> we dont have to discuss it now.. but when there are more people (next week?) 22:01 < rsLeo> ok. cu next week 22:02 <@emostar> alright, good night! --- Log closed Wed Apr 12 22:02:42 2006
pgpRUOP9qOAAz.pgp
Description: PGP signature
