Re: [Evolution-hackers] Front-end header files for E-D-S libraries
On Tue, 2011-03-22 at 14:35 -0400, Matthew Barnes wrote: For 3.1, I would like to provide a top-level header file for each of the libraries in E-D-S and deprecate including individual header files. The benefits should be clear by now: more flexibility to change or rearrange header files without breaking the public API. Hi, I never got why one wants this, I recall some Java guidelines which encourage the opposite, never include whole unit, but only pieces you actually use. It made more sense to me, to not get in things you never use (quicker parsing/compilation too, probably, to not openparse spare header files). Also, one does not rearrange code so often, I believe. Anyway, if you really think this change (which actually affects anyone using eds client API) worth the effort, then feel free to do it. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Front-end header files for E-D-S libraries
On Di, 2011-03-22 at 14:35 -0400, Matthew Barnes wrote: For 3.1, I would like to provide a top-level header file for each of the libraries in E-D-S and deprecate including individual header files. The benefits should be clear by now: more flexibility to change or rearrange header files without breaking the public API. How much of a problem is that in practice? I have to deal with compatibility problems in all of the current releases already: * URI changes and data migration in 2.32 * account/config changes in 3.0 * and now header file changes in 3.1 If the header file change had been done such that a single = 3.0 check is enough I wouldn't mind, but it doesn't seem like 3.0 has a libebook.h (picking just one example). Is there a chance to add the headers to 3.0 before it gets released? If not, then I'd prefer to not make this change. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Front-end header files for E-D-S libraries
On Wed, 2011-03-23 at 13:42 +0100, Patrick Ohly wrote: How much of a problem is that in practice? It's getting to be a problem. Seemingly innocent changes to header files break builds in unexpected ways. Here's a common scenario: - Header file foo.h includes bar.h. - A client program includes foo.h and uses things defined there. - Later, the client program starts using things defined in bar.h, but forgets to include it explicitly. It just happens to work because foo.h includes it. - Down the road, foo.h no longer includes bar.h for some reason or another. Maybe to resolve a cyclic dependency between the two. - The client program now fails to build, because bar.h was never explicitly included. Forcing the client program to include a front-end header file for the library, which itself includes both foo.h and bar.h, avoids this problem. This is why most other libraries already do it this way. Another scenario is when a pair of header/body files is getting to be overly bloated and complicated and developers would like to divide it into smaller files so it's easier to understand and maintain. Without a front-end header file for the library we don't have the flexibility to do this with without breaking the public API. Is there a chance to add the headers to 3.0 before it gets released? It's too late for 3.0.0. I can add it for 3.0.1 sans the preprocessor warnings if that would help. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Front-end header files for E-D-S libraries
On Mi, 2011-03-23 at 09:05 -0400, Matthew Barnes wrote: On Wed, 2011-03-23 at 13:42 +0100, Patrick Ohly wrote: How much of a problem is that in practice? It's getting to be a problem. Seemingly innocent changes to header files break builds in unexpected ways. Here's a common scenario: [...] Okay, I see your point. But if the split into individual files is merely to group code and not done to speed up compilation, wouldn't the following also work: 1. move current files into an internal sub-directory 2. introduce the new include all header 3. make all the traditional names symlinks to that one header That introduces the desired advantage (rearrange header content) without breaking the API. Is there a chance to add the headers to 3.0 before it gets released? It's too late for 3.0.0. I can add it for 3.0.1 sans the preprocessor warnings if that would help. 3.0.1 is too late to help much, unless 3.0.0 can be expected to not be used by anyone... -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Front-end header files for E-D-S libraries
On Wed, 2011-03-23 at 15:52 +0100, Patrick Ohly wrote: I thought that this break would go into 3.0 (see my initial reply). So if 3.1 requires changes anyway, then sure, go ahead and break it some more ;-) Oh, I missed that in your first reply. Sorry. That was the plan originally, but keeping up with GTK3 prior to its first stable release sucked up huge amounts of time during 2.91, at least for me. So a lot of my goals for 3.0 got pushed out. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Backend requesting arbitrary user input from frontend
Hi all. Part of the overall evolution-kolab project is to make it possible for Evolution (as a Kolab client) to use TPM [1] infrastructure. In short, it's all about certificate based client authentication, where clients can be forced to authenticate themselves against a server when establishing an SSL connection. It's the SSL server certificate based auth the other way around - first, the server will identify itself by sending a signed (and therefore, hopefully, trusted server certificate), then, the client will authenticate itself to the server by sending a signed client certificate. Only after the client sent a known, signed and trusted certificate, the server will ask for service authentication (username/password). If the client cannot authenticate, the server will terminate the SSL connection. Using a TPM means that the client certificate is stored within a hardware crypto token, the Trusted Platform Module. To open and use the crypto token, the user needs to supply a user PIN (much like a password). Then only the crypto token will be accessible and will reveal the client certificate (or other data) it was asked for. Via the PKCS#11 stack (implemented through opencryptoki [2] and trousers [3]), it is possible to use this under Linux. It is working for Camel (via NSS) already. Given the proper setup, the Evolution frontend will pop up a PIN requester where the user can enter his/her crypto token PIN, and the crypto token reveals the client certificate to NSS for use in certificate-based client auth. This means that Camel can also use it. It works for us, there is a draft installation and setup guide available in the evolution-kolab project on SourceForge [4], namely Usage_of_software_security_devices_for_client_authentication.pdf (check out the Files section). We can secure e.g. an Evo IMAP connection that way. Now, we're using Camel (to be more specific: IMAPX) in our evolution-kolab backend, since all Kolab PIM data is stored in emails accessible via IMAP. We would like to use the TPM crypto device there as well, but we're lacking a possibility how we can request a user PIN from within the backend process through the frontend, since there is no API which would allow us to open a requester in the frontend (like, displaying some explanatory text, and having a field to enter some text, and an ok/cancel button, the entered text being handed back to the backend). This lack is there at least in 2.30, for which evolution-kolab is currently being developed (porting to newer versions is in the plannings, once we're done with the initial 2.30 release). Maybe this is a more general thing than just having a backend requesting a user PIN. I can imagine other scenarios where a backend might need to request any user interaction, input, whatsoever, which is specific to this backend and cannot be taken care of in the existing general EDS API (which is limited to the typical things all backends need to do). I'd like to know your thoughts on this, and maybe other backend implementors already had a similar need to request some user data which is not readily available through the standard EDS backend API. Kind regards, Christian [1] http://en.wikipedia.org/wiki/Trusted_Platform_Module [2] http://sourceforge.net/projects/opencryptoki/ [3] http://trousers.sourceforge.net/ [4] https://sourceforge.net/projects/evolution-kolab/ -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Backend requesting arbitrary user input from frontend
Hi again, Am Mittwoch 23 März 2011, um 18:03:32 schrieb Christian Hilberg: Hi all. [...] Maybe this is a more general thing than just having a backend requesting a user PIN. I can imagine other scenarios where a backend might need to request any user interaction, input, whatsoever, which is specific to this backend and cannot be taken care of in the existing general EDS API (which is limited to the typical things all backends need to do). [...] Of course, this is going to be fun - how to tell which of the possibly multiple EDS-frontends should receive the request? Ideally, the backends should be unaware of EDS-frontends... trouble galore! :) (Bye)^2, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
