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
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 this, plus I have couple other
bugs pending in my todo before I get free
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
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 to
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 whic
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 draf
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 ECl
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
>
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 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 s
Hi everyone,
being back in the office and having cleaned up my desk,
let's heat up this topic again, so it hopefully will
get us somewhere.
Am Dienstag 03 April 2012, um 10:52:00 schrieb Christian Hilberg:
> Hi everyone.
> [...]
> Back in version 2.30, Evolution has not had a dedicated "synchroni
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 bac
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
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, s
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 main motivation for
> developing SyncEvolution. I know from others tha
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"
> > chec
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 EDS+Evo
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 b
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:
> 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, u
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):
>
> Thinki
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 chan
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
updat
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, M
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 o
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 sign
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?
>
> Just rough thinking, nothing elaborate as yet - I'll be
> 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 s
On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote:
> 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
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 goi
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 com
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?
>
> Just rough thinking, nothing elaborate as yet - I'll be
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"
>
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
Hi Matt,
Am Dienstag 03 April 2012, um 17:11:56 schrieb Matthew Barnes:
> 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
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)
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
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 r
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 se
Am Dienstag 03 April 2012, um 10:52:00 schrieb Christian Hilberg:
> Hi everyone.
> [...]
> Effectively, I am lacking a mechanism which tells my backend that the user
> wants to synchronize the local cache (evolution implements a full offline
^-- evolu
Hi everyone.
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.
Back in version 2.30, Evolution has not had a dedicated "synchronize"
button, but there has been the online/offline butt
41 matches
Mail list logo
