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
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
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
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:
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
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
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
