On Sunday 30 October 2005 05:33, Harry Vennik wrote: > Op zondag 30 oktober 2005 14:24, schreef Tom Jenkins: > > Harry Vennik wrote: > > >Op zondag 30 oktober 2005 13:39, schreef Tom Jenkins: > > >>GrdScarabe wrote: > > >>>If I understood how you'd like it to work, it would be something like > > >>> : > > >>> > > >>> +-----------------------------+ > > >>> > > >>> | Skin | > > >>> > > >>> +-----------------------------+ +------------------+ > > >>> > > >>> | GUI | | Plugins | > > >>> > > >>> +-----------------------------+ +------------------+ > > >>> ^GUI2Core Protocol (events)^ ^Plugins interface^ > > >>> +--------------------------------------------------+ > > >>> > > >>> | aMSN Core | > > >>> > > >>> +--------------------------------------------------+ > > >>> ^Protocol2aMSN Protocol^ > > >>> +-----------------------------+ > > >>> > > >>> | Communication Protocol | > > >>> | abstraction layer | > > >>> > > >>> +-----------------------------+ > > >>> > > >>> | MSN | Jabber | ... | > > >>> > > >>> +-----+--------+--------------+ > > >> > > >>Yeah thats the kind of idea :) Although the way I see it, there won't > > >> be a "core", just several parts that all work together. > > > > > >I'd say this is way to complex a view on it. It will be sloooooow! Just > > > have a event handling system (available already), and have plugins. No > > > more than that. Implement the protocol part as a plugin, and do the > > > same with the GUI, and it's as clean, modular and flexible as it can > > > ever be! > > > > Isn't that what the diagram shows? Well anyway, the idea is that we will > > have: Protocol fires an event, gui picks it up, and does something with > > the info. ANd yup, it will all be clean, modular and flexible :P Cause > > we lurrve that. > > Eh, and what may the Communication Protocol Abstraction Layer be??? In a > good events-based design, it will resolve to 'nothing'. > And why don't I ever hear you guys saying anything about the GUI generating > events, that are picked up by the protocol part? Just because you regard it > as a core part, rather than a plugin! And it needs to be a plugin, if we > want to keep the option to implement other IM protocols, as well as making > implementation of new MSNP versions possible without having to scatter the > code with ifs, as is being done now for MSNP11. > > so the schema is then: > > +-------------------------------------+ > > | Plugins | > | (UIs / Protocols / Extensions) | > > +-------------------------------------+ > v Events ^^^ > +-------------------------------------+ > > | Core | > | (Event dispatching system) | > > +-------------------------------------+ > I would be quite interested in working on the Core part as I have experience working with the current plugin system and have some ideas on how to adapt it to work with "Core" plugins and "user" plugins.
One more thing that would be have to be done is to create global and per-user plugins. Global plugins are ones that get loaded on amsn start and user plugins are those that get loader on user login. -- Karol Krizka
pgpSk8u4mW6SP.pgp
Description: PGP signature
