. It would be great to be pointed into the
right directions here.
Questions galore - any helpful input will be kindly appreciated. :)
Best regards,
Christian Hilberg
--
kernel concepts GbRTel: +49-271-771091-12
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
, Christian Hilberg wrote:
We'll check that out with other Gnome projects. It may take some more
research on the project itself before we know how to actually accomplish
the testing stuff. My thoughts atm tend towards cunit/expect and/or the
GLib testing framework.
I think the consensus from
Hi there,
I'm trying to dig up the EDS data structure which is currently used to hold
calendar data. Searching the sources (among others, evolution-mapi), I found
ECalComponent
being used as a toplevel data structure for calendar data. Regarding this data
structure, I found:
Hi there,
reading about the new IMAPX implementation used by Evo =2.30, I found it
stated that
Maybe if imapx had come up before, many backends such as groupwise, mapi
etc. would have followed this design rather than a sync one.
-- Chenthill in [1]
Does this mean
Hi all,
searching evolution-hackers about Evolution coding style, I found
http://projects.gnome.org/evolution/patch.shtml
referenced as the coding style reference ;-) for Evolution. Is this document
still fully valid so we may use it as style guide for our project? Are there
any
On Thursday 01 Juli 2010 at 13:01:22 Matthew Barnes wrote:
On Thu, 2010-07-01 at 11:43 +0200, Christian Hilberg wrote:
searching evolution-hackers about Evolution coding style, I found
http://projects.gnome.org/evolution/patch.shtml
[...]
That's still more or less valid. There's
On Thursday 01 Juli 2010 at 13:30:26 Tor Lillqvist wrote:
style. patch.shtml talks about 8-space-tabs
Just some nitpicking here: I hate it when people say loosely that tabs
correspond to 8 spaces (or four, or whatever).
For good reason. :-) Just quoted
Hi Michael,
On Wednesday 26 May 2010 at 12:18:04 Michael Meeks wrote:
Hi Christian,
[...]
It'd be better really to develop vs. master - from a support, testing,
future-proofing, and ease-of-use perspective. Presumably it is possible
to get you commit access to the repository so you
concepts)
Christian Hilberg (kernel concepts)
Hendrik Helwich (tarent)
Umer Kayani (tarent)
More resources may be allocated as needed. :)
About the project
The goal of the evolution-kolab project is to provide a plugin for Evo/EDS
which will allow Evo users
Hi all,
in evolution-kolab, we need to provide full offline capabilities for working
with Kolab 2 groupware data in offline mode.
Evo 2.30 has an offline mode which works for IMAP email. If I understood
correctly, email handling resides within Evolution presently [1], not E-D-S.
For our
Hi Michael,
On Thursday 08 Juli 2010 at 17:01:36 Michael Meeks wrote:
[...]
On Thu, 2010-07-08 at 10:28 +0200, Christian Hilberg wrote:
We will try to map as much of Kolab's functionality as possible onto
Evolution whithout changing Evolution itself (other than providing a
plugin
On Thursday 08 July 2010 at 15:50:19 Christian Hilberg wrote:
Hi all,
in evolution-kolab, we need to provide full offline capabilities for
working with Kolab 2 groupware data in offline mode.
Anything? Anyone? :-)
Best regards,
Christian
--
kernel concepts GbRTel: +49-271
On Friday 09 July 2010 at 18:01:53 chen wrote:
[...]
Let me try to summarize some pointers for calendar and you could do the
same for address-book as well,
+ Create New ECalBackend for Kolab
+ Use the camel apis to fetch the calendar folder
+ Using the CamelFolder, get its contents. You
Hi Chen,
thank you very much for taking time to clarify things! Much appreciated.
On Friday 09 July 2010 at 18:43:32 chen wrote:
On Fri, 2010-07-09 at 18:25 +0200, Christian Hilberg wrote:
* Does there exist any infrastructure in E-D-S which will help us
creating a local email cache via
Hi again,
no ideas? Anything?
Best regards,
Christian
--
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/
signature.asc
Description: This is a digitally signed message part.
Hi,
On Thursday 08 July 2010 Matthew Barnes wrote:
I finally finished converting Camel's error handling code to GError.
CamelException is no more.
Is there a sensible way how we could deal with CamelException in our
evolution-kolab plugin, which will be developed against 2.30? This is, can
On Tuesday 13 July 2010 Matthew Barnes wrote:
On Tue, 2010-07-13 at 18:50 +0200, Christian Hilberg wrote:
Is there a sensible way how we could deal with CamelException in our
evolution-kolab plugin, which will be developed against 2.30? This is,
can CamelException be wrapped in a way which
Hi there,
On Wednesday 14 July 2010 Ross Burton wrote:
On Wed, 2010-07-14 at 20:14 +0530, chen wrote:
Though only subclass this if you can't handle the async nature of the
ECalBackend API yourself. Whether you subclass ECalBackend or
ECalBackenSync is a choice made by how the backend
Hi all,
regarding Unit-testing our plugin, we've settled on the GLib Testing framework
and Unit tests written in C.
Now, when doing integration testing, we will certainly try to automate a few
things.
Question is: does there exist a preferred scripting tool / language within the
Evolution
Hi all,
within the evolution-kolab plugin, we would like to display extended free-busy
information if some is available on the Kolab server.
Extended f/b lists have some text attached to the busy information for any
user within the same calendaring group. This feature is provided by the Kolab
Hi all,
...the story continues...
As a part of our project, we need to support TPM hardware as certificate
source for client-authentication against client-auth-enabled services. Within
Kolab context, these are mainly IMAPS, SMTPS, LDAPS and HTTPS. The tpm-tools
suite and openCryptoki will
Hi all,
...still continuing...
Kolab makes use of RFC5464 - The IMAP METADATA Extension IMAP folder
annotations to differentiate between the various folder types which are
handled by Kolab. Remember, anything (Email and PIM data) is stored as Email
messages with XML attachments in IMAP
On tuesday 20 July 2010 Christian Hilberg wrote:
[...]
From within Evolution, *only* the IMAP folder which is annotated Email
^^
the IMAP folders which are annotated, this is.
Best regards,
Christian
--
kernel
Hi there,
thanks Milan for your reply.
On Tuesday 20 Juli 2010 Milan Crha wrote:
On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote:
Is it possible to define certain IMAP folders as hidden from within
our plugin's EPlugin part? Or is it possible to hide certain IMAP
folders
Hi there,
On Tuesday 20 July 2010 chen wrote:
On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote:
[...]
Is it possible to define certain IMAP folders as hidden from within
our plugin's EPlugin part? Or is it possible to hide certain IMAP
folders (and their subfolders
Hi Milan,
thanks for your explanations, though they undermine what little idea about
Evolution design I thought I had... ;-)
On Friday 23 July 2010 Milan Crha wrote:
On Fri, 2010-07-23 at 10:43 +0200, Christian Hilberg wrote:
We would need the possibility to define extra D-Bus communication
Hi again.
On Monday 26 July 2010 Christian Hilberg wrote:
while I suspect the answer will most likely be no, just to be sure I'd
like to put the question here anyway (if only for the record):
Does the Camel IMAPX implementation comply with RFC5464 The IMAP METADATA
Extension [1] ?
[...]
[1
Hi Matthew,
thanks for the prompt reply.
On Wednesday, 04 August 2010 Matthew Barnes wrote:
On Wed, 2010-08-04 at 12:50 +0200, Christian Hilberg wrote:
Using the Camel.HttpStream should do the trick - is that correct? I've
seen the Camel.HttpStream being used within Anjal (file
em-format
Hi there,
On Wednesday 04 August 2010 Matthew Barnes wrote:
On Wed, 2010-08-04 at 13:28 +0200, Christian Hilberg wrote:
Does libsoup make use of NSS (just the newbie's uninitiated question)?
It uses GnuTLS for transport layer security.
http://www.gnu.org/software/gnutls/
Is there any good
Hi Matthew,
On Wednesday, 04 August 2010, Matthew Barnes wrote:
On Wed, 2010-08-04 at 16:03 +0200, Christian Hilberg wrote:
Is there any good alternative to using libsoup which makes use of NSS?
We're pretty much depending on the (mostly) working NSS infrastructure
for PKCS #11 and token
Hi again,
On Wednesday 04 August 2010 Christian Hilberg wrote:
On Wednesday, 04 August 2010, Matthew Barnes wrote:
On Wed, 2010-08-04 at 16:03 +0200, Christian Hilberg wrote:
Is there any good alternative to using libsoup which makes use of NSS?
We're pretty much depending on the (mostly
Hi there,
On Thursday 05 August 2010 Matthew Barnes wrote:
On Thu, 2010-08-05 at 18:30 +0200, Christian Hilberg wrote:
Result: While libsoup should build against the current GnuTLS lib
(development version, 2.11.0), which has PKCS #11 support since a few
weeks now, libsoup has
Hi Stef,
On Friday 06 August 2010 Stef Walter wrote:
[...]
FWIW, gnutls is working on PKCS#11 support. The first bits have been
added and I've been working with the gnutls maintainers on some of the
remaining parts. I believe libsoup will start using this in the near
future.
Yes, we've seen
Hi.
In the backend code for our plugin, we will need to handle two IMAPX providers
simultaneously, one for the address book backend and one for the calendar
backend.
Normally, there will be a single Camel.Session instance only. Will this be
true in our case as well, when there are multiple
Hi everyone,
On Thursday 05 August 2010 David Woodhouse wrote:
On Wed, 2010-08-04 at 12:22 +0200, Christian Hilberg wrote:
Now, I would like to know how we should deal with the issue. We (the
evolution-kolab developers) could patch the 2.30 version of IMAPX only to
get things running
Hi everyone,
searching Evolution lists, docs and source, I found that supporting IMAP4 ACLs
has been discussed now and then, but I could not deduce from what I've read
that the IMAP/IMAPX providers actually do support ACLs.
Support for IMAP ACLs would be very useful when dealing with a Kolab
On Wednesday 25 August 2010 David Woodhouse wrote:
∄ ACL support in imapx.
Thanks for the information (though I was hoping for a different one :-).
(Bye)^2,
Christian
--
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
Hi everyone.
After some time working on different places within our Plugin, I'm back to our
IMAPX part.
braindump
We would like to use the IMAPX implementation for our backends as well as for
the Evolution Email part when Kolab access is configured.
Thing is, we cannot just use the plain
Hello again.
While working through the IMAPX sources, I noticed that there are three kinds
of licenses in the headers for the *.[hc] files of the IMAPX implementation:
* GPLv2
* LGPLv2
* {nil}
The COPYING file in the E-D-S toplevel directory states LGPLv2, this is what
we checked initially.
Hi,
On Thursday 09 September 2010 Christian Hilberg wrote:
[...]
ANNOTATEMORE and METADATA differ in the syntax they use and they have some
minor semantic differences.
[...]
Just for your reference:
RFC5464 - The IMAP METADATA Extension
http://www.faqs.org/rfcs/rfc5464.html
IMAP
Hi,
On Friday 16 Juli 2010 Matthew Barnes wrote:
On Fri, 2010-07-16 at 15:54 +0200, Christian Hilberg wrote:
Within our project it has been brought up that POSIX shell scripts might
be a good choice in order to keep a low profile depencency-wise.
Personally, I would prefer a higher-level
Hi everyone.
JFYKI: There is a public Git repo online now with some sources for the
evolution-kolab plugin. If you like, check out
http://sourceforge.net/projects/evolution-kolab/
The repo is not open for public commits, though.
Please be aware that this code is very much pre-alpha and not at
On Friday 17 September 2010 Christian Hilberg wrote:
[...]
There is a mailing list which should become acessible over the weekend.
It's there now.
(Bye)^2,
Christian
--
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072
Hi,
On Thu 20 January 2011 Matthew Barnes wrote:
On Thu, 2011-01-20 at 18:24 +0100, Milan Crha wrote:
Nope, go for it. It may also fix an issue with BirthdayAnniversaries
calendar, when using authenticated addressbook, as right now there is no
easy way to ask for a stored password for that
Hi Matt,
On Thu 27 January 2011 Matt Davey wrote:
I'm not sure this is the right list, as this is more of a policy
question than a dev question.
I recently logged a bug (#639970) that crops up every now and again for
me, and it was closed as OBSOLETE because I raised it against Evolution
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
Hi Milan,
On Wed 30 March 2011 Milan Crha wrote:
On Wed, 2011-03-23 at 19:04 +0100, Christian Hilberg wrote:
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
Hi everyone.
While working on the evolution-kolab plugin, we found that there is no direct
support in ECalComponent for attachments inlined into calendar objects. Thus,
so far, we can cope with attachments inlined into Kolab calendar objects by
hiding them in private ical fields. That way, we
Hi everyone,
thanks for the input so far.
On Friday 08 April 2011 David Woodhouse wrote:
On Fri, 2011-04-08 at 10:35 +0200, Milan Crha wrote:
On Fri, 2011-04-08 at 10:04 +0200, Christian Hilberg wrote:
We could use Evolution's file-link attachment mechanism by writing into
Evos file
On Friday 08 April 2011 Milan Crha wrote:
[...]
With respect of fetch on demand, it'll be tricky to achieve, to make
this done right on each operation which deals with the calendar
component in a certain way (operations like copy, move, send and so on).
But there is some API function,
Hi everyone.
After a prolonged silence and a period of much work, the evolution-kolab team
gladly announces what you could call a first release candidate of the Kolab
plugin for Evolution (in fact, it is, only it has not officially been tagged
as one).
Source code, packages, user manual and
Hi everyone.
Since the last announcement of the evolution-kolab team here on the list, our
source code (hosted at http://evolution-kolab.sourceforge.net/) has seen some
more polishing and now compiles on Debian/Squeeze in addition to Ubuntu/Lucid.
We will make available a (source) release
Hi,
On Thu 07 July 2011, Chenthill wrote:
On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote:
Since neither my kernel concepts evolution-kolab team mates nor myself
have done upstream integration for an Evolution plugin yet, I would like
to know how we should best proceed from here
Hi everyone,
On Thursday 07 July 2011, Matthew Barnes wrote:
On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote:
The first step could be to create an evolution-kolab git repository at
gnome.org, at least this is what came to my mind instantly. In order to get
the prerequisites
Hi,
On Friday, 15 July 2011, Matthew Barnes wrote:
Sorry for the delayed response...
NP at all, thanks for your input!
[...]
The process really isn't as formal as the wiki makes it out to be.
Because you're an extension module for an application that has already
met these requirements,
Hi all,
Am Montag 12 September 2011, um 09:57:26 schrieb Milan Crha:
On Fri, 2011-09-09 at 22:18 -0400, Matthew Barnes wrote:
I got this working today. Would anyone object if I create the
gnome-3-2 branch early next week so I can commit this for 3.3.1 and
then rebase my account-mgmt
Hi there,
just one bit of nitpicking:
Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes:
[...]
The EExtension framework was introduced in Evolution 2.30 as part of the
Shouldn't that read 2.32? At least, the wiki
Hi again,
Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes:
[...]
The API
is already fully documented and our wiki has usage instructions for it:
http://live.gnome.org/Evolution/Extensions
Is the list of EExtensible-tagged classes listed at the end of the wiki
Hi,
I hope I've got the reference right...
Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes:
[...]
I'm going to need EExtension for the new D-Bus service I talked about
recently [1] anyway, so it makes sense to get this part merged early.
Kind regards,
Christian
Hi all.
During the initial implementation of the evolution-kolab plugin, we were
concerned with using hardware crypto devices (TPM, trusted platform module) as
a means to store and retrieve client certificates for securing TLS connections
to a Kolab server (by configuring the Kolab server to
Hi all,
Am Donnerstag 25 August 2011, um 18:46:15 schrieb Matthew Barnes:
[...]
Proposal:
I think the key file management needs to be centralized in a new D-Bus
service, tentatively called e-source-registry. The ESourceRegistry
singleton class in client programs would then be a proxy for
Hi Milan,
Am Dienstag 13 September 2011, um 07:33:31 schrieb Milan Crha:
On Mon, 2011-09-12 at 13:16 +0200, Christian Hilberg wrote:
We succeeded doing so for the following protocols: HTTPS, IMAPS, SMTPS.
These are protocols handled by Camel and the underlying NSS library. In
order
schrieb Christian Hilberg:
[...]
[3]
http://mail.gnome.org/archives/evolution-hackers/2011-September/msg00030.html
--
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
Hi Milan,
Am Mittwoch 14 September 2011, um 08:25:20 schrieb Milan Crha:
On Tue, 2011-09-13 at 15:56 +0200, Christian Hilberg wrote:
* IMAP ACL management. A new tab (or something alike) when
right-clicking an IMAP folder in the Evo folder tree to view and
edit IMAP access control
Hi,
Am Dienstag 18 Januar 2011, um 20:32:44 schrieb Matthew Barnes:
[...]
Now I'll let you in on my master plan:
Either in the 3.2 or 3.4 time frame, after the branch is merged and has
some time to settle in and stabilize, I want to move these configuration
dialogs to
Hi there,
I know it is muc hlate for input, but anyway, here we go:
Am Donnerstag 21 April 2011, um 18:43:27 schrieb Matthew Barnes:
To help smooth the way for the account-mgmt I've made a few improvements
to the CamelSession and CamelService APIs in 3.1. It's not necessarily
the *final*
Hi all.
Am Dienstag 13 September 2011, um 15:56:00 schrieb Christian Hilberg:
The evolution-kolab team is currently planning to port the evolution-kolab
plugin to the recent developer version of Evo/E-D-S. I have had a discussion
[...]
In order to get a clearer picture of the changes in Evo
Hi all,
thanks to Matt, here are another two which I initially missed (since I was much
clear that Camel would move to GObject/GError/GIO...):
--
Thread:
Hi there,
Am Donnerstag 29 September 2011, um 17:35:04 schrieb Matthew Barnes:
On Thu, 2011-09-29 at 09:13 +0200, Milan Crha wrote:
I think I mentioned it earlier, and maybe this is the right time, what
about replacing e- prefix with evolution- prefix for process names?
There was a
Hi Matthew,
Am Samstag 15 Oktober 2011, um 17:18:27 schrieb Matthew Barnes:
Just a heads up that I've changed Camel's authentication API to factor
out the password loop that each and every provider currently replicates
for themselves. Turns out they all have the same basic logic flow.
[...]
Hi there,
Am Montag 17 Oktober 2011, um 14:51:08 schrieb Matthew Barnes:
On Mon, 2011-10-17 at 11:44 +0200, Christian Hilberg wrote:
I take it this new password API deals with IMAP|POP|SMTP|... service
passwords _only_, i.e. service user authentication?
Correct. I don't have a good
Hi Matthew,
Am Montag 17 Oktober 2011, um 23:48:01 schrieb Matthew Barnes:
On Mon, 2011-10-17 at 15:21 +0200, Christian Hilberg wrote:
Fair enough, thanks for clarifying. If that's the current status, then
nothing is lost if we keep the implementation as-is for now and try it
again later
Hi everyone!
The evolution-kolab team gladly announces the availability of version 0.30.0
of the evolution-kolab plugin for the Evolution PIM suite.
The major improvements over our previous release (Version 0.2.1) include overall
speedup fixes to most operations as well as a good number of
Am Dienstag 15 November 2011, um 15:01:54 schrieb Christian Hilberg:
Am Dienstag 15 November 2011, um 11:03:24 schrieb Patrick Ohly:
[...]
What happens during syncing? Do you resolve the add-add conflict by
duplicating the item, merging them or discarding one copy
Hi Patrick,
Am Mittwoch 16 November 2011, um 15:55:54 schrieb Patrick Ohly:
Hello!
[...]
On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote:
If a new UID is to be created, it is the responsibility of the Kolab client
to
assign one. The Kolab server itself is unaware to object
Hi,
Am Freitag 18 November 2011, um 16:53:38 schrieb Patrick Ohly:
On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote:
[...]
While the E-D-S client (like Evo) might not be interested whether it is
a Kolab backend being used, there is still one thing you may wish to
consider here
Hi,
the evolution-kolab plugin now has a mailing list, please see [1].
Everyone who is interested in following the discussions there is
invited to subscribe. I estimate this list to be a low-traffic one,
at least for some time. :)
I'll post links into the archive of the
Hi David,
Am Dienstag 06 Dezember 2011, um 22:29:46 schrieb David Woodhouse:
On Tue, 2011-12-06 at 17:03 +0100, Christian Hilberg wrote:
the evolution-kolab plugin now has a mailing list, please see [1].
Everyone who is interested in following the discussions there is
invited to subscribe
Hi everyone.
In evolution-kolab [1], we use an IMAPX derivative for accessing
the Kolab groupware server via IMAP.
Since
(a) Camel does not expose IMAPX directly and
(b) IMAPX is not yet cleanly subclassable in all aspects and
I need to keep a copy of upstream IMAPX in the evolution-kolab
Hi Matt,
Am Freitag 03 Februar 2012, um 16:46:50 schrieb Matthew Barnes:
On Fri, 2012-02-03 at 15:53 +0100, Christian Hilberg wrote:
I need to replicate some code paths of IMAPX (e.g. all paths that
lead from the Store to imapx_untagged, so I can extend this one
for ANNOTATEMORE and later
Hi everyone,
Am Montag 26 März 2012, um 05:03:14 schrieb Matthew Barnes:
You may have noticed Evolution 3.4.0 and co. has been released and I've
created 'gnome-3-4' branches for all modules except 'evolution-mapi' and
'evolution-kolab' (but I assume Milan and Christian will take care of
those
Hi Matt,
thanks a lot for picking up this topic, as it is quite essential for us.
Maybe others can join in as well in order to iron out what would be needed
here.
Am Dienstag 03 April 2012, um 14:14:52 schrieb Matthew Barnes:
On Tue, 2012-04-03 at 10:52 +0200, Christian Hilberg wrote:
Next
Hi,
Am Sonntag 01 April 2012, um 11:13:00 schrieb Robie Basak:
Hi freeassociation-devel,
I think I've tracked down a segfault in evolution to a bug in libical.
In icaltimezone.c:icaltimezone_get_builtin_timezone,
icalarray_append(builtin_timezones, ...) is called. This can cause
Am Dienstag 03 April 2012, um 18:05:33 schrieb Matthew Barnes:
On Tue, 2012-04-03 at 17:29 +0200, Christian Hilberg wrote:
Seems to me that opening a connection in order to find out whether I could
open a connection is more than evo-kolab would need. Unless the
service-available
check
2012, um 12:24:58 schrieb Milan Crha:
On Tue, 2012-04-03 at 13:33 -0400, Matthew Barnes wrote:
On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote:
Just rough thinking, nothing elaborate as yet - I'll be meditating
this. :)
Rough thinking here too. I'll let it simmer
Hi there,
Am Mittwoch 04 April 2012, um 19:11:46 schrieb Matthew Barnes:
On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote:
How about the service-available to be set much like the to-be
network-available, through GNetworkMonitor, as an EBackend property,
which, when changed, emits
Hi,
...also re-posting here instead of our more private thread, in order
to get these things into public, for the record and for discussion:
Am Donnerstag 05 April 2012, um 11:09:37 schrieb Milan Crha:
Hi,
just an out-of-thread idea (initially opened in another discussion):
Thinking
Hi,
Am Mittwoch 04 April 2012, um 15:09:36 schrieb Milan Crha:
On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote:
[...]
As for evolution-kolab, sadly, there is no good way to do a quick check
for
changes, at least I do not have an idea how one could implement one, since
Hi,
Am Freitag 13 April 2012, um 11:54:51 schrieb David Woodhouse:
On Tue, 2012-04-10 at 21:51 +0200, Patrick Ohly wrote:
On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote:
Which is the long-term vision for Evolution in this regard?
Lack of proper offline support has been my
Hi all,
Am Dienstag 08 Mai 2012, um 01:11:50 schrieb Philip Withnall:
On Mon, 2012-05-07 at 17:17 +0200, Christian Hilberg wrote:
Moreover, there's a GSoC project (see
https://live.gnome.org/SummerOfCode2012/Ideas)
for a backend cache infrastructure (the Ideas page still outlines
Hi Matt,
Am Montag 07 Mai 2012, um 18:17:05 schrieb Matthew Barnes:
On Mon, 2012-05-07 at 17:17 +0200, Christian Hilberg wrote:
It has already been agreed upon (see previous posts in this thread) that
such a synchronize() function is needed and that it can be triggered
from the EClients
Hi everyone,
had a chat with Chen on IRC today about the topic. Since he had
to leave, I'll try to sum up our findings here, for the record
and for review, please see the inline comments.
Am Mittwoch 23 Mai 2012, um 10:00:27 schrieb Christian Hilberg:
Am Dienstag 22 Mai 2012, um 16:38:20
Hi again,
Am Mittwoch 23 Mai 2012, um 18:05:29 schrieb Christian Hilberg:
Passing in the user payload data showed to be specifically tricky.
As dwmw2 just pointed out on IRC, it really isn't.
The data structures which the derivative untagged handlers
need to access can/should best be bound
And again...
Am Mittwoch 23 Mai 2012, um 18:40:34 schrieb Christian Hilberg:
Hi again,
Am Mittwoch 23 Mai 2012, um 18:05:29 schrieb Christian Hilberg:
Passing in the user payload data showed to be specifically tricky.
As dwmw2 just pointed out on IRC, it really isn't.
The data
Hi everyone.
Each time we release a new version of Evolution, E-D-S and the
plugins, http://projects.gnome.org/evolution/download.shtml requires
a manual update. New plugins, like evolution-kolab, are easily
missed in the process. As for the 3.5 line of evolution-kolab, Matt
had even added an
Hi again,
Am Dienstag 03 April 2012, um 10:52:00 schrieb Christian Hilberg:
While porting evolution-kolab from Evolution 2.30 to 3.4.x (and on
to 3.5 later on), I have been stumbling upon an issue regarding
groupware server synchronzation.
[...]
Effectively, I am lacking a mechanism which
Hi all,
Am Dienstag 08 Mai 2012, um 11:52:00 schrieb Christian Hilberg:
It has been a while [0] since the idea of making IMAPX
subclassable / extendable for backends to use. Time to
bring the topic back into the public again. :-)
There is a bugzilla entry [1] now for the topic, and Chen
Hi,
Am Mittwoch 09 Mai 2012, um 09:28:53 schrieb Milan Crha:
On Tue, 2012-05-08 at 10:56 +0200, Christian Hilberg wrote:
@Milan: Do you think you could post your API work here at e-h list?
That would give us something to base our discussion on. Even if no
GSoC student picks up the topic
Hi all,
Am Dienstag 19 Juni 2012, um 19:55:36 schrieb Reid Thompson:
out of tree build requires the following manual intervention...
15001 cp evolution-data-server/libedataserver/*.h
obj/evolution-data-server/libedataserver/
15002 cp evolution-data-server/camel/*.h
1 - 100 of 112 matches
Mail list logo
