Hi Milan,
Am Mittwoch 20 Juni 2012, um 19:36:19 schrieb Milan Crha:
On Wed, 2012-06-20 at 11:08 +0200, Christian Hilberg wrote:
Has someone been working on this thing yet?
Hi,
I do not know about anyone (current fires about account-management
branch merge got higher priority than
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,
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,
On Wed, 2012-06-20 at 10:49 +0200, Christian Hilberg wrote:
In our lengthy discussion about that topic, we found that a synchronize()
method is desired for the backends and EClient would expose this in its
API. How exactly the various E-D-S clients will represent this functionality
in their
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, your work should not be lost.
Hi,
sure, the initial draft
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
a
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
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 in a sensible way. Question is, how and when will it
be implemented so
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
a Contact cache - is this up-to-date?).
Via
KolabMailSideCache
and
On Fri, 2012-04-13 at 10:54 +0100, David Woodhouse wrote:
I really wouldn't want to see us reinventing the wheel and trying to
do full sync and conflict resolution in Evolution — not in a generic
way for all Evo back ends to use, and *especially* not over and over
again in the different back
On Tue, 2012-04-03 at 12:05 -0400, Matthew Barnes wrote:
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 would be
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
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 main motivation for
developing SyncEvolution. I know from others that they, too, would love
to see this supported natively in
Hi,
hmm, I'm afraid I do not follow. It also doesn't seem 'simplified' with
4 different properties. I understand what the current online and
readonly properties are good for, on both EClient side and backend
side, but I do not understand these four.
On Wed, 2012-04-04 at 13:11 -0400,
Hi,
just an out-of-thread idea (initially opened in another discussion):
Thinking of it, dealing with conflicts while writing changes into the
server when in online mode is simple, the backend just returns an error
and doesn't try to resolve anything. Am I right? It should eventually
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
On Thu, 2012-04-05 at 12:05 +0200, Christian Hilberg wrote:
This is why I propose a dedicated offline state, which is not dependent on
network availability, and which is visible to the user by being displayed
in each client that connects to E-D-S. Such a state makes it very clear to
both, user
On Thu, 2012-04-05 at 08:31 -0400, Matthew Barnes wrote:
Need to think on that some more, but can we at least agree that
capability would be _in addition_ to the properties I proposed for
EBackend, so I can start implementing a few of them?
I would say no :) At least not before your account
On Thu, 2012-04-05 at 12:05 +0200, Christian Hilberg wrote:
If the backend has no notion of a dedicated offline state, and such
is not visible in Evolution or any other client, how does the backend
tell whether to report an error that the object could not be stored on
the server and has been
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,
this thread is getting quite
Hi Milan,
thanks a lot for joining us and for writing the nice summary!
This is much appreciated. If the mail thread becomes too long
and overly complicated, it may make sense to drop the findings
into a wiki page and work it out from there.
First of all, no, the things discussed here are not
On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote:
First of all, no, the things discussed here are not going to be
easy, and it raises the question what Evolution actually wants
to be. Does it want to be a fully offline-capable PIM/groupware
client? That means, does it want to
On Wed, 2012-04-04 at 13:11 -0400, Matthew Barnes wrote:
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 a signal?
On Wed, 2012-04-04 at 21:25 +0100, Philip Withnall wrote:
Nitpicky, but what happens if a backend has to deal with multiple hosts?
The only example I can think of at the moment, and it's a stretch, is
the Google Contacts backend. It connects to one host for authentication,
and a different one
On Tue, 2012-04-03 at 10:52 +0200, Christian Hilberg wrote:
Next part is, that I think network (un)availability and Evolution/E-D-S
online/offline state are two separate things, which got mixed in the
current implementation. Network unavailability means I cannot write my
objects onto the
Might want to repost your full message to the list. I assume you didn't
mean to reply to me privately?
On Tue, 2012-04-03 at 16:05 +0200, Christian Hilberg wrote:
Well okay, that's a little more than the current EBackend online property,
since it can tell me whether a certain host can be
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
On Tue, 2012-04-03 at 10:40 -0400, Matthew Barnes wrote:
g_network_monitor_can_reach() takes a GSocketConnectable -- which is
just an interface that's implemented by several concrete classes like
GNetworkAddress (based on host name and port number) and GNetworkService
(based on SRV records),
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 would be really cheap, it seems to me that host-reachable would
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
32 matches
Mail list logo
