On Mo, 2011-04-18 at 15:57 +0200, Milan Crha wrote:
I just created a new branch 'eclient' in eds [1] where is added my work
on the new API which will deprecate EBook/ECal. It is following glib/gio
async pattern and, I believe, makes things more coherent.
First of all, +1 for rethinking the
On Di, 2011-04-19 at 16:03 +0200, Milan Crha wrote:
On Tue, 2011-04-19 at 09:27 -0400, Matthew Barnes wrote:
There's a couple other simple things I forgot to mention yesterday.
* We should add some padding to all the public class structs so we can
add new class methods in the future
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
Are you saying that a soname version bump can and should be done in a
backwards-incompatible way (= code compiled against older version no
longer works with new lib)? That's a major pain for people trying to
support multiple distros.
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
First of all, +1 for rethinking the API. I'd like to suggest that
besides modernizing the API we also take this opportunity to move more
of EBook/ECal into a common core.
Opening and listing databases don't have to be separate. Turn
On Thu, 2011-04-28 at 13:12 +0100, David Woodhouse wrote:
As I understand it, an soname bump (from libfoo.so.5 to libfoo.so.6)
should *only* be used for backwards-incompatible changes.
Correct. One such example of a backwards-incompatible change is
increasing the size of a public GObject
On Do, 2011-04-28 at 08:17 -0400, Matthew Barnes wrote:
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
First of all, +1 for rethinking the API. I'd like to suggest that
besides modernizing the API we also take this opportunity to move more
of EBook/ECal into a common core.
Hello!
As part of wrapping QtContacts around EDS [1] I ran into the same issue
that Nokia already encountered in their Maemo 5 [2] backend: EDS uses
strings as ID, QtContacts 32 bit integers.
Nokia solved that by setting up an in-memory hash which maps the UID
string to its CRC-16. I don't see
[please reply to the list only, it makes my life worse when you CC me]
On Thu, 2011-04-28 at 08:17 -0400, Matthew Barnes wrote:
It would mean EClient has to know that ECalClient and EBookClient exist
in order to instantiate the right one for a given enum value. Normally
in class design you
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
* 32 bit IDs - check whether (read) or ensure that (write) IDs
are 32 bit integers instead of strings, simplifies
QtContacts-EDS [2]; I have a patch which reduces the size of
IDs
from 64 bit to 32 in the file
On Thu, 2011-04-28 at 16:37 +0200, Milan Crha wrote:
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
* 32 bit IDs - check whether (read) or ensure that (write) IDs
are 32 bit integers instead of strings, simplifies
QtContacts-EDS [2]; I have a patch which
On Thu, 2011-04-28 at 16:34 +0200, Milan Crha wrote:
You obviously face of a circular dependency, so it's not doable in a
clean way. Also because EClient is in libedataserver, EBookClient in
addressbook/libebook and similarly ECalClient in calendar/libecal. Both
descendants link to
On Thu, 2011-04-28 at 11:59 -0400, Matthew Barnes wrote:
On Thu, 2011-04-28 at 16:34 +0200, Milan Crha wrote:
You obviously face of a circular dependency, so it's not doable in a
clean way. Also because EClient is in libedataserver, EBookClient in
addressbook/libebook and similarly
On Thu, 2011-04-28 at 18:11 +0200, Milan Crha wrote:
Yes, when I was changing server side data-views for book and cal, then
if turned out that the D-Bus API is exactly the same except of the
DBUS_PROXY_NAME and book/cal strings in a file.
Thus having type param for both factories too,
On Thu, 2011-04-28 at 14:49 +0200, Patrick Ohly wrote:
Please, let's avoid E_CLIENT_TYPE_CALENDAR. For people less familiar
with Evolution terminology it is not clear whether this includes tasks.
In Evolution, it doesn't, but in other contexts it does. For example,
Nokia phones store events
On Thu, 2011-04-28 at 12:35 -0400, Matthew Barnes wrote:
This may also be of benefit to Srini and his email-factory branch. I
can imagine extending the enum to include E_CLIENT_TYPE_MAIL_STORE or
something similar.
Only the last thing for the enum values, I would personally prefer
something
On Thu, 2011-04-28 at 21:16 +0200, Patrick Ohly wrote:
Agreed, the library dependency issue is a problem. That could be solved
by an utility library on top of libecal and libebook which offers the
unified API.
Or you could just write your own function in EvolutionSync. It's just a
switch
On Thu, 2011-04-28 at 15:04 -0400, Matthew Barnes wrote:
On Thu, 2011-04-28 at 19:53 +0200, Milan Crha wrote:
Only the last thing for the enum values, I would personally prefer
something with a prefix E_CLIENT_SOURCE_TYPE_... only to not have it
confusion-able with E_CLIENT_TYPE constant.
17 matches
Mail list logo
