[Evolution-hackers] Most of the providers don't have to link with libedataserver
Hi there,
As far as I can see is the only camel provider dat uses libedataserver
directly, the groupware one. The other camel providers don't use any of
the libedataserver functionality hence shouldn't link with it.
Not linking might improve dlopen() times. Because by the time the .so is
loaded, not linking isn't going improve memory consumption (on a normal
desktop system) a lot, indeed.
However, it's imo good to have dependencies and build environment
correct, and not in a state of ... oh, maybe it's used, maybe not, so
we'll just add it to the LIBADD. Nah :), not-so-nice imo.
ps. Note that Camel itself only uses a very small subset of the
function- ality of libedataserver. This could be fixed by splitting up
the library in a libedataserver-common and a libedataserver-specific,
and let camel only link with the libedataserver-common.
ps. I indeed have the patches and list-of-files (and tests) ready to do
this. It should perhaps be discussed first, so let me know if you want
this (maybe we can discuss it next #evolution-meet?)
This is the list of files Camel uses from libedataserver: e-trie.c,
e-iconv.c, e-memory.c, e-msgport.c, e-sexp.c, e-time-utils.c,
e-data-server-util.c, md5-utils.c and of course their .h files. The
files compile (without any changes) without needing any of the other
libedataserver code files.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
Index: hula/Makefile.am
===
RCS file: /cvs/gnome/evolution-data-server/camel/providers/hula/Makefile.am,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile.am
--- hula/Makefile.am 14 Nov 2005 17:39:32 - 1.1
+++ hula/Makefile.am 20 Jul 2006 07:53:40 -
@@ -20,7 +20,6 @@ libcamelhula_la_SOURCES = \
libcamelhula_la_LDFLAGS = -avoid-version -module $(NO_UNDEFINED)
libcamelhula_la_LIBADD =\
- $(top_builddir)/libedataserver/libedataserver-1.2.la \
$(top_builddir)/camel/libcamel-provider-1.2.la \
$(top_builddir)/camel/libcamel-1.2.la \
$(CAMEL_LIBS)
Index: imap4/Makefile.am
===
RCS file: /cvs/gnome/evolution-data-server/camel/providers/imap4/Makefile.am,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile.am
--- imap4/Makefile.am 12 Aug 2005 23:51:34 - 1.12
+++ imap4/Makefile.am 20 Jul 2006 07:53:40 -
@@ -43,7 +43,6 @@ libcamelimap4_la_SOURCES = \
libcamelimap4_la_LDFLAGS = -avoid-version -module $(NO_UNDEFINED)
libcamelimap4_la_LIBADD = \
- $(top_builddir)/libedataserver/libedataserver-${API_VERSION}.la \
$(top_builddir)/camel/libcamel-provider-1.2.la \
$(top_builddir)/camel/libcamel-1.2.la\
$(CAMEL_LIBS)
Index: imap/Makefile.am
===
RCS file: /cvs/gnome/evolution-data-server/camel/providers/imap/Makefile.am,v
retrieving revision 1.34
diff -u -p -r1.34 Makefile.am
--- imap/Makefile.am 19 May 2006 15:25:08 - 1.34
+++ imap/Makefile.am 20 Jul 2006 07:53:40 -
@@ -42,7 +42,6 @@ noinst_HEADERS = \
libcamelimap_la_LDFLAGS = -avoid-version -module $(NO_UNDEFINED)
libcamelimap_la_LIBADD = \
- $(top_builddir)/libedataserver/libedataserver-${API_VERSION}.la \
$(top_builddir)/camel/libcamel-provider-1.2.la \
$(top_builddir)/camel/libcamel-1.2.la\
$(CAMEL_LIBS)
Index: local/Makefile.am
===
RCS file: /cvs/gnome/evolution-data-server/camel/providers/local/Makefile.am,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile.am
--- local/Makefile.am 12 Aug 2005 23:51:34 - 1.20
+++ local/Makefile.am 20 Jul 2006 07:53:41 -
@@ -57,7 +57,6 @@ noinst_HEADERS =\
libcamellocal_la_LDFLAGS = -avoid-version -module $(NO_UNDEFINED)
libcamellocal_la_LIBADD = \
- $(top_builddir)/libedataserver/libedataserver-${API_VERSION}.la \
$(top_builddir)/camel/libcamel-provider-1.2.la \
$(top_builddir)/camel/libcamel-1.2.la\
$(CAMEL_LIBS)
Index: nntp/Makefile.am
===
RCS file: /cvs/gnome/evolution-data-server/camel/providers/nntp/Makefile.am,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile.am
--- nntp/Makefile.am 12 Aug 2005 23:51:35 - 1.32
+++ nntp/Makefile.am 20 Jul 2006 07:53:41 -
@@ -35,7 +35,6 @@ noinst_HEADERS = \
libcamelnntp_la_LDFLAGS = -avoid-version -module $(NO_UNDEFINED)
libcamelnntp_la_LIBADD = \
- $(top_builddir)/libedataserver/libedataserver-${API_VERSION}.la \
$(top_builddir)/camel/libcamel-provider-1.2.la \
$(top_builddir)/camel/libcamel-1.2.la\
$(CAMEL_LIBS)
Index: pop3/Makefile.am
===
RCS file: /cvs/gnome/evolution-data-server/camel
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Mon, 2006-07-17 at 15:35 -0400, JP Rosevear wrote: > > I think you're only real example is camel, which shares code with the other > pieces anyhow. Knowing is a good idea. These are the files Camel needs from libedataserver. Nothing more, nothing less: e-trie.c, e-iconv.c, e-memory.c, e-msgport.c, e-sexp.c, e-time-utils.c, e-data-server-util.c, md5-utils.c -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Thu, 2006-07-13 at 11:35 +0100, Ross Burton wrote: > On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote: > > I wasn't (am no longer) proposing to move "camel/" out of e-d-s. I was > > proposing to put a configure.ac file in its directory. Moving Camel out > > of evolution-data-server/ is not the scope nor point of this thread. > > For what purpose? Camel depends on libedataserver. Small correction: It depends on e-trie.c, e-iconv.c, e-memory.c, e-msgport.c, e-sexp.c, e-time-utils.c, e-data-server-util.c, md5-utils.c which is compiled in libedataserver. These files themselves don't depend on anything other in libedataserver. I also have a clean configure.ac ready that will only build a Camel, and a set of Makefile.am's that will build a static libedataserver using only the listed files above. Stripped a fully functional Camel x86 build uses 315K for libcamel, 339K for libcamel-provider and 868K for camel-providers/* -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Hot Patch Action
Hi, We're coming up to the freezes, so I thought I'd ping the lists with some patches that are sitting in bugzilla for libebook: http://bugzilla.gnome.org/show_bug.cgi?id=318880 Change an internal table to match an external enum, thus changing linear searches into array index lookups. http://bugzilla.gnome.org/show_bug.cgi?id=347899 Adds some more mutators of EVCard so that values and parameters can be removed without having to jump through loops. http://bugzilla.gnome.org/show_bug.cgi?id=330255 Add a new query, e_book_query_vcard_field_exist(), to match on arbitrary vcard fields. All of these patches are in Maemo so have been tested. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] A tool to build a lighter camel: camel-lite-builder
Note: I mistakenly sent this to the patches mailing list first. I hope I will not get slaughtered for that. My apologises. Hi there, This camel-lite-builder tool to build a light version of Camel. It will, using a script that should be invoked before the autogen.sh (or configure), get the original Camel sources from the original repository (I will of course make sure that the repository will always point to the right one. For example in case of a Subversion migration). It doesn't use a branch, it uses the HEAD of Camel. Except applying the mmap patch, it doesn't change code. To avoid this patching (which could be interpreted as forking, but for me it certainly isn't), I might switch to the mmap branch that will be created soon. It will apply a small patch to some Makefile.am files of Camel. This to make sure that the providers don't unnecessarily link with libedata- server and so that libcamel can link with a static version of a size reduced libedataserver. There's a libedataserver that I don't checkout from the original repos- itory because I had isolate the files that are needed. Compiling only those reduces .so file size. I might change this by getting it from the repository and afterwards letting the script delete the unneeded files (if that makes people feel better about it, I certainly will). The Makefile.am of libedataserver, however, needs a more intrusive change. The one that you can find in this repository will build it as a noinst static library. http://svn.tinymail.org/svn/camel-lite-builder/trunk/ I on purpose called it a "builder". This is to avoid confusing it with a fork, which it isn't. The primary target audience for the resulting Camel binaries will be people who want to test E-mail clients based on tinymail on mobile devices that don't come with evolution-data-server or with a version of evolution-data-server that doesn't contain the mmap patches nor a future improvement. I might consider renaming the libcamel .so to libcamel-lite to avoid any type of clashing. I'm not sure if that would make people feel bad about it smelling like a fork. If so, I will most certainly not do that and I will allow "Camel" packages to detect a installation of a "Camel" that was build using camel-lite-builder, so that they can upgrade to a version of "Camel" that isn't build by camel-lite-builder. The idea is to keep the "Camel" that comes out of camel-lite-builder ABI and API compatible with a normal Camel build. I've put "Camel" between double quotes not to show that there's a difference, but to show that there's "no" difference. Both are "Camel". -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Thu, 2006-07-20 at 10:05 +0200, Philip Van Hoof wrote: > On Mon, 2006-07-17 at 15:35 -0400, JP Rosevear wrote: > > I think you're only real example is camel, which shares code with the other > > pieces anyhow. > > Knowing is a good idea. Hrmm. After re-reading my own stuff, I apologise for the tone. I'm not afraid of admitting when I make a mistake. I'll rewrite: I think it's interesting to know on which code-pieces Camel depends. This will make future decisions and discussions about it more easy. For that reason I decided to investigate it a little it. It turns out only the following files are being used by Camel: e-trie.c, e-iconv.c, e-memory.c, e-msgport.c, e-sexp.c, e-time-utils.c, e-data-server-util.c, md5-utils.c -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] ESourceGroup from ESource
On Wed, 2006-07-19 at 18:09 -0700, Scott Herscher wrote: > How does one derive an ESourceGroup from an ESource? If I call > e_source_peek_group() with a valid ESource instance, and then immediately > call E_IS_SOURCE_GROUP(), I am getting false. > Was the ESource got from ESourceList ? If so, ESourceList object should be alive while accessing the ESource, otherwise ESourceGroup would be NULL if the corresponding ESourceGroup was not ref'ed. - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libecal functions
On Wed, 2006-07-19 at 11:25 -0400, Teresa Thomas wrote: > Hi > I have one last (hopefully) question about libecal. I want to add a > VEVENT to an existing Evolution calendar. > > Hence, I created an iCalComponenent to be added and hope to use the > e_cal_create_object(ECal* eCal,iCalComponent iCalcomp, char** uid, > char** error) function. > > Now, I understand that eCal is a calendar client. If I want to add my > event to an Evolution calendar, what exactly should eCal contain? Is > it some sort of an identity of a cal? If so, how can I obtain it. ECal client can be obtained by using the function e_cal_new, by passing an ESource. ESource holds the settings required for a calendar client which is stored in gconf. The client is associated with the backend through the protocol specified in the uri stored in ESource. Eg: uri starting with file:/// would refer to file backend, contacts:// would be pointing to contacts backend. - Chenthill. > > Thanks! > On 7/19/06, Teresa Thomas <[EMAIL PROTECTED]> wrote: > Thanks Mr Palanisamy! > > My Bad, I actually meant to ask about the function > e_cal_component_new() in ECalComponent.h/c. > Anyway, from what I understand it returns an ECalComponent, > which is an (easier to manipulate) wrapper around an > iCalComponent. > > > > On 7/19/06, chenthill palanisamy <[EMAIL PROTECTED]> > wrote: > On Tue, 2006-07-18 at 17:44 -0400, Teresa Thomas > wrote: > > Need some assistance in my quest to comprehend EDS. > > > > What exactly is the difference between > e_cal_create_object() [in > > ECalComponent] and e_cal_create_object() [in > ECal ] ? > e_cal_create_object is used to create a appointment, > task or a memo > object (ECalComponent) in the corresponding backend > (file, http, > groupwise etc). There is no function named > e_cal_create_object in > ECalComponent. There is a function > e_cal_component_get_created which > gives the creation date of a ECalComponent. > > Please have a look at > http://www.go-evolution.org/EDS_Architecture . > > > - Chenthill. > > > > > > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Some brainstorming about CamelMessageContentInfo
About my tone: this is a brainstorming tone and E-mail.
I'm questioning things. I am NOT trying to illustrate some people are
idiots.
I grew up with the idea that hackers and coders constantly question
things and yes, also each other. Question question question .. question
everything. Always question everything.
My intention here is to help you guys find the memory of Evolution. I'm
not trying to present myself als the person who's almighty good at
finding memory problems. I simply question a lot and keep kicking and
trying things until I find it. Valgrind is just a tool, my questioning
is my true technique.
I use the brainstorming tone and I'm questioning whether my conclusions
and ideas make sense. I'm not trying to contest people or telling them
my solution is the fucking best of the world. That's not the point.
I hope after a few days/weeks people here will understand my methodology
when I do this type of E-mails. Because I think a lot of the problems
with past discussions where simply based on wrong conclusions and errors
in the communication itself. We don't have our body language here. I
miss it, because I would use that a lot on you guys.
This is the CamelMessageContentInfo struct.
struct _CamelMessageContentInfo {
struct _CamelMessageContentInfo *next;
struct _CamelMessageContentInfo *childs;
struct _CamelMessageContentInfo *parent;
CamelContentType *type;
char *id;
char *description;
char *encoding; /* this should be an enum?? */
guint32 size;
};
With
typedef struct {
char *type;
char *subtype;
struct _camel_header_param *params;
unsigned int refcount;
} CamelContentType;
If your provider sets "build_content" of the CamelFolderSummary to TRUE,
camel it will create an instance of this struct for all your headers.
It looks like the IMAP provider of Camel does this. Which is fine, of
course. If there's also actually something interesting in it.
It seems that only the "type" pointer is usefully filled in after
checking for now 46,000 headers in my IMAP folders.
The id, description and encoding are for all these 46k headers is set to
NULL.
Not THAT bad, you might think? :-) There's plenty of memory!
Except for the fact that each pointer on a x86 consumes four bytes. Let
us calculate!
4 bytes * 3 pointers * 46,000 headers equals 552,000 bytes or 539kb.
I have a few folders that are sized 20,000 headers. For each such
header, there's 12 bytes wasted in NULL's. Who here has counted all the
headers his Evolution *can* show in his current session? Multiply that
with 12 and divide that with 1024*1024, that is how much megabytes your
Evolution is consuming for just this.
I have a mobile phone that has FAR less memory then my Evolution
currently has NULL pointers ;-)
This would slightly improve this situation (and don't allocate extra if
there's nothing interesting in id, description and encoding).
struct _CamelMessageContentInfo {
struct _CamelMessageContentInfo *next;
struct _CamelMessageContentInfo *childs;
CamelContentType *type;
CamelMessageContentInfoExtra *extra;
guint32 size;
};
struct _CamelMessageContentInfoExtra {
char *id;
char *description;
char *encoding; /* this should be an enum?? */
};
Or what about this? Because CamelContentType are also 3 pointers and an
int on top of it. The type and subtype could be done using a mechanism
like the camel_pstring_add.
struct _CamelMessageContentInfo {
struct _CamelMessageContentInfo *next;
struct _CamelMessageContentInfo *childs;
char *type, *subtype;
CamelMessageContentInfoExtra *extra;
guint32 size;
};
struct _CamelMessageContentInfoExtra {
char *id;
char *description;
char *encoding; /* this should be an enum?? */
};
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-patches] Avoiding a strdup in camel-folder-summar.c
On Wed, 2006-07-12 at 02:28 +0530, Ritesh Khadgaray wrote: > > out of curiosity, the first patch reads through the list > and this patch, return if any one of the token is equal, anf not any > following it. > > Would the below not be better ? > > for (i = 0; i < tokens_len; i ++) > if (tokens[i] != token) > break; That will free the token in the list. Chris ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libecal functions
Okay that makes sense. When I enter gconftool-2 --get /apps/evolution/calendar/sources on the terminal, it lists all the ESources.Now, does each ESource have some sort of an identity that I can send as the ESource* parameter to the e_cal_new() function? Or is their some way I can access the ESources using any functions [I see that there is a get_source() function in EBookBackend]. If so, can you elaborate on the value of parameters that I have to send to such a function. Or do I have to construct the ESource on my own (parse the data obtained from gconftool and assign corresponding data members) ?ThanksOn 7/20/06, chenthill palanisamy <[EMAIL PROTECTED]> wrote: On Wed, 2006-07-19 at 11:25 -0400, Teresa Thomas wrote:> Hi> I have one last (hopefully) question about libecal. I want to add a> VEVENT to an existing Evolution calendar.>> Hence, I created an iCalComponenent to be added and hope to use the > e_cal_create_object(ECal* eCal,iCalComponent iCalcomp, char** uid,> char** error) function.>> Now, I understand that eCal is a calendar client. If I want to add my> event to an Evolution calendar, what exactly should eCal contain? Is > it some sort of an identity of a cal? If so, how can I obtain it.ECal client can be obtained by using the function e_cal_new, by passingan ESource. ESource holds the settings required for a calendar client which is stored in gconf. The client is associated with the backendthrough the protocol specified in the uri stored in ESource.Eg: uri starting with file:/// would refer to file backend, contacts://would be pointing to contacts backend. - Chenthill.>> Thanks!> On 7/19/06, Teresa Thomas <[EMAIL PROTECTED]> wrote:> Thanks Mr Palanisamy!>> My Bad, I actually meant to ask about the function > e_cal_component_new() in ECalComponent.h/c.> Anyway, from what I understand it returns an ECalComponent,> which is an (easier to manipulate) wrapper around an> iCalComponent. On 7/19/06, chenthill palanisamy <[EMAIL PROTECTED]>> wrote:> On Tue, 2006-07-18 at 17:44 -0400, Teresa Thomas > wrote:> > Need some assistance in my quest to comprehend EDS.> >> > What exactly is the difference between> e_cal_create_object() [in > > ECalComponent] and e_cal_create_object() [in> ECal ] ?> e_cal_create_object is used to create a appointment,> task or a memo > object (ECalComponent) in the corresponding backend> (file, http,> groupwise etc). There is no function named> e_cal_create_object in > ECalComponent. There is a function> e_cal_component_get_created which> gives the creation date of a ECalComponent.>> Please have a look at > http://www.go-evolution.org/EDS_Architecture .>>> - Chenthill.> >> >>> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
