On Di, 2011-06-14 at 07:38 -0400, Matthew Barnes wrote:
On Tue, 2011-06-14 at 12:08 +0200, Patrick Ohly wrote:
My two cents as a user of these APIs: having to deal with a major API
change once is acceptable. Whether it is in 3.2 or 3.4 I don't really
care.
But having to rewrite code
On Do, 2011-06-09 at 12:25 -0400, Matthew Barnes wrote:
On Thu, 2011-06-09 at 17:11 +0200, Milan Crha wrote:
I hope not, I'm currently working on evo bits to be buildable with
E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED defined (eds is
done, but I'm postponing it till I have evo
On Tue, 2011-06-14 at 12:08 +0200, Patrick Ohly wrote:
My two cents as a user of these APIs: having to deal with a major API
change once is acceptable. Whether it is in 3.2 or 3.4 I don't really
care.
But having to rewrite code both for 3.2 *and* 3.4 goes a bit too far. So
if the account
On Thu, 2011-06-09 at 17:11 +0200, Milan Crha wrote:
I hope not, I'm currently working on evo bits to be buildable with
E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED defined (eds is
done, but I'm postponing it till I have evo and the standard rest done
as well). Having one API
(I cannot Ctrl+L the message)
On Thu, 2011-06-09 at 12:25 -0400, Matthew Barnes wrote:
On Thu, 2011-06-09 at 17:11 +0200, Milan Crha wrote:
I hope not, I'm currently working on evo bits to be buildable with
E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED defined (eds is
done, but
On Thu, 2011-06-09 at 18:40 +0200, Milan Crha wrote:
By the way, thinking of your announcement, I hope you are fine if I'll
finish this stop using deprecated Book/Cal API in evo as soon as
possible and commit it, thus it'll have more testing (I'm pretty sure
I'll introduce few regressions and
On Thu, 2011-06-09 at 13:15 -0400, Matthew Barnes wrote:
Yes, please do get us using the async EClient APIs in Evolution ASAP.
I can deal with the impact to the branch -- I don't expect it to be too
severe.
Thanks, I'll do that. Just the first transition will be about not using
deprecated API,
On Thu, 2011-06-09 at 22:48 +0200, Milan Crha wrote:
Thanks, I'll do that. Just the first transition will be about not using
deprecated API, the second part of it, making calls async, is a very
different task, as I go through calendar sources and see all the sync
calls and the API being served
Hi,
I just committed changes from 'eclient' branch to eds' master branch.
This will be part of evolution-data-server 3.1.2.
I'll adapt evolution-exchange, evolution-mapi, evolution-groupwise and
evolution-couchdb for the API and opening phase changes. Feel free to
poke me if you've any
On Fri, 2011-04-29 at 07:24 -0400, Matthew Barnes wrote:
On Fri, 2011-04-29 at 06:59 +0200, Milan Crha wrote:
There was just a little problem with ECalView, which had 'client'
property, which is referring to ECal, instead of ECalClient, and I was
forced to invent different name for it. But
On Fri, 2011-04-29 at 06:59 +0200, Milan Crha wrote:
There was just a little problem with ECalView, which had 'client'
property, which is referring to ECal, instead of ECalClient, and I was
forced to invent different name for it. But after a bit of sleeping
and small thinking I might be wrong
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.
[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.
On Fri, 2011-04-22 at 13:58 -0400, Matthew Barnes wrote:
The idea though is that what we do now in e-passwords.c -- namely
checking GNOME Keyring for a password and building and displaying our
own password dialog to the user -- is *one possible* implementation of
that simple abstract
On Thu, 2011-04-21 at 08:32 +0200, Milan Crha wrote:
On Tue, 2011-04-19 at 17:00 +0200, Milan Crha wrote:
On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote:
I would like you to a incorporate some change to the free/busy api.
Some servers allow querying free/busy information
On Thu, 2011-04-21 at 12:51 -0400, Matthew Barnes wrote:
On Thu, 2011-04-21 at 17:11 +0200, Milan Crha wrote:
It's technically not passed in this function, it's a callback
signature. :) It would be used as a signal handler for auth-required
signal in the function, as I think of it right
On Fri, 2011-04-22 at 19:03 +0200, Milan Crha wrote:
Yup, though it'll be (internally - aka in D-Bus) still a signal. This
request of ECredentials object seems strange to me, because I understand
the ECredentials as something which actually holds credentials, not
something what is asking for
On Tue, 2011-04-19 at 17:00 +0200, Milan Crha wrote:
On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote:
I would like you to a incorporate some change to the free/busy api.
Some servers allow querying free/busy information
for multiple users at a time and the results appear in a
On Tue, 2011-04-19 at 13:12 -0400, Matthew Barnes wrote:
Then I can pass that ECredentials object any time I need to create a
new EClient. I just call e_cal_client_new() or e_book_client_new(),
pass the ECredentials object along with some ESource, wait for the
callback, and I'm done. I can
On Thu, 2011-04-21 at 08:41 +0200, Milan Crha wrote:
void e_client_open_new (ESource *source, gboolean (* auth_cb) (EClient
*client, ECredentials *credentials, gpointer user_data), gpointer
user_data);
gboolean e_client_open_new_finish (GAsyncResult *result, EClient
**client, GError
On Thu, 2011-04-21 at 08:34 -0400, Matthew Barnes wrote:
On Thu, 2011-04-21 at 08:41 +0200, Milan Crha wrote:
void e_client_open_new (ESource *source, gboolean (* auth_cb) (EClient
*client, ECredentials *credentials, gpointer user_data), gpointer
user_data);
gboolean
On Thu, 2011-04-21 at 17:11 +0200, Milan Crha wrote:
It's technically not passed in this function, it's a callback
signature. :) It would be used as a signal handler for auth-required
signal in the function, as I think of it right now.
Yeah I'd like to kill the auth-required signal too as I've
On Tue, 2011-04-19 at 19:02 -0400, Matthew Barnes wrote:
On Tue, 2011-04-19 at 23:25 +0100, David Woodhouse wrote:
Note the 'gboolean retrying' argument to the libsoup authenticate
signal handler. We probably want to have something similar in the above
API too, because that's what tells
On Tue, 2011-04-19 at 07:58 +0200, Milan Crha wrote:
* In EBookClient, drop the 'const' qualifier from EContact arguments.
Trying to use 'const' with GObjects is misguided and pointless. I've
cursed at EIterator many times for this.
Yet another thing I wanted to address was a clear
On Tue, 2011-04-19 at 09:27 -0400, Matthew Barnes wrote:
Havoc Pennington kept having to answer this same type of thing in the
early days of GLib/GTK+ when people would ask why the API never uses
const in functions that take but don't modify a GObject and GLib data
structure.
On Mon, Apr 18, 2011 at 10:18 PM, Matthew Barnes mbar...@redhat.com wrote:
On Mon, 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
On Mon, 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.
There's a few other weightier issues
On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote:
I would like you to a incorporate some change to the free/busy api.
Some servers allow querying free/busy information
for multiple users at a time and the results appear in a iterative
fashion. The freebusy information of some
On Tue, 2011-04-19 at 16:03 +0200, Milan Crha wrote:
No, not at all, EClient calls descendant's get_capabilities_sync on its
own, when it's needed. The public get_capabilities API on descendants is
sort of redundant in this case.
It that case we should have:
void
On Tue, 2011-04-19 at 10:40 -0400, Matthew Barnes wrote:
1) There's no need for apps to use numeric IDs to track asynchronous
operations; GCancellable fills that role. GCancellable is the app's
handle to the ongoing operation. If the app wants to cancel an
unfinished operation, it
On Tue, 2011-04-19 at 18:37 +0200, Milan Crha wrote:
Hmm, I think I understand, but I do not see clearly the point. Sometimes
you do not know if the server requires the authentication, only after
open, which will deliver (on idle) the auth-required signal, which can
come before the backend
On Tue, 2011-04-19 at 10:40 -0400, Matthew Barnes wrote:
2) ECredentials is way too complex. My intent for ECredentials was to
have a self-contained authentication handling interface to avoid all
the current nonsense with ECal and EBook where you have to always
remember to connect
On Tue, 2011-04-19 at 23:25 +0100, David Woodhouse wrote:
Note the 'gboolean retrying' argument to the libsoup authenticate
signal handler. We probably want to have something similar in the above
API too, because that's what tells the UI that it needs to ditch the
existing remembered password
Hey,
I haven't had a chance to look at it all in detail, but two things
strike me from a quick glance:
• If we're following the GIO async pattern, why do the
e_data_book_respond_*() functions still exist?
• Please, please, please add some documentation to the new EDataBook.
Trying to
On Mon, 2011-04-18 at 15:36 +0100, Philip Withnall wrote:
I haven't had a chance to look at it all in detail, but two things
strike me from a quick glance:
• If we're following the GIO async pattern, why do the
e_data_book_respond_*() functions still exist?
Hi,
the server part
On Mon, 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.
Thanks for posting this, Milan. I
On Mon, 2011-04-18 at 12:48 -0400, Matthew Barnes wrote:
* There's some overlap between the new EClient API and the new
ESource API that I'm working on. Some functions will need to be
dropped once the new ESource API is in place, so I don't know if
you want to do this now or wait.
...
51 matches
Mail list logo
