Re: [Evolution-hackers] Bug #127546 Gaim Evolution presence integration.

I appear to be having trouble sending to this listserv from my normal
account, so we'll try this one...

A couple comments on the Gaim side of things.

First, why is there a separate evogaimremote? The Gaim side is
functionality that shouldn't have to be considered evolution-specific.
Furthermore, you make the assumption in the code that the user will
have evolution-data-server, which will very often not be the case.

Also, if you can follow the Gaim coding conventions, that'd be great. 
Indentation levels, naming conventions, line length, Doxygen comment
styles, using our debug API instead of glib's or printfs where
appropriate, static functions where appropriate, etc. Thanks.

Mainly, I just don't see a need for evo-specific code in there. It can
be done in a more abstract way. Remember that for code to be accepted
into Gaim, it must be written with other platforms and programs in
mind. We've been working hard at tearing out the platform-specific and
UI-specific bindings in the code there. We don't want to take a step

You're also going to run into a problem real soon in gaim. We're
redoing the status API (based off of Galago), and it will be very
incompatible with your current work. The packets, for instance, will
have to change format, and operations aren't going to work the same
way. There will be a lot more data to convey as well. The status
rewrite is not ready yet, and I don't think it's in a state where
development can be done off of it, but just a heads up.

I see a lot of rewrite work in libgaim-remote that I'm not sure is
needed, like replacing structs with ints and such. Why is it now
multi-threaded? This could surely be done differently.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]