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
ContentInfo *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-te
On Sat, 2006-07-22 at 00:00 +0300, Tor Lillqvist wrote:
> on 2006-07-12 klockan 19:13 +0200 skrev Philip Van Hoof:
> > It simply looks like Evolution developers didn't know where to stack all
> > these Evolution libraries. And thought .. oh, we already had this
> > &qu
.
At this moment that size is ~ (12+80+36+8+12) bytes per header.
--
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
_
On Tue, 2006-08-22 at 16:54 +0200, Philip Van Hoof wrote:
> You can repeat this testing using the tests in the tinymail framework:
Also make sure you read this page:
http://tinymail.org/trac/tinymail/wiki/HelpMemoryTesting
Don't forget to perform G_SLICE=always-malloc and G_DEBUG=gc-
(or both). The ideal tool to make yourself look like a
cool developer at managers and project leaders that don't understand a
lot about whatever valgrind outputs. And useful to get a first
impression of when and how-many memory is being allocated in an
interactive application (like Evolution).
that? It doesn't, right?
So what is this hack about? If I disable it and let it return the
offline "get_folders" method of the provider, everything works perfect
for every provider.
I see strange code. While I'm awake. Begin used like regular code. It
doesn't crash. Only developers
#x27;t always happen.
Making me wonder: Why not simply replace CamelObject with GObject? And
what is this "check_magic" thing anyway? It seems to loop over a
inheritance tree or something like that.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome
On Fri, 2006-08-25 at 12:32 +0200, Jules Colding wrote:
> On Fri, 2006-08-25 at 12:10 +0200, Philip Van Hoof wrote:
> > Camel hackers,
> >
> > It's not clear from the gtk-doc API documentation* whether or not you
> > must unreference a store after getting
th, PROT_READ,
MAP_SHARED, open (index_file, ...));
fs->istart = mmap (0, length, PROT_READ,
MAP_SHARED, open (summary_file, ...));
return fs;
}
CamelMessageInfo*
camel_message_info_get (CamelFolderSummary *fs, int nth)
{
CamelMessageInfo *i = malloc (sizeof *i);
i->fs = fs;
i->nt
On Thu, 2006-09-07 at 21:14 +0200, Philip Van Hoof wrote:
> typedef struct {
> CamelFolderSummary *fs;
> int nth;
> MemoryMessageInfo *m;
> } CamelMessageInfo;
>
>
> #define camel_message_info_from (x) \
> ((x)->m ? (x)->m-
On Thu, 2006-09-07 at 21:14 +0200, Philip Van Hoof wrote:
> To read message n, you would simply do something like:
>
> from = sstart + *(istart + (sizeof (int) * 4 * n) + 1)
> subject = sstart + *(istart + (sizeof (int) * 4 * n) + 2)
> to = sstart + *(istart + (sizeof (int) * 4 *
but then using 4k pages in the kernel).
Viewing and scrolling, using this implementation, was already fast
enough on a mobile device like the Nokia 770. I'm not going to call is
"snappy" fast. Just "fast enough" or "acceptable fast".
I am now, like Evolution, goin
On Thu, 2006-09-07 at 21:48 -0500, Federico Mena Quintero wrote:
> On Thu, 2006-09-07 at 21:14 +0200, Philip Van Hoof wrote:
>
> > The *new*/*extra* idea is to create a second index file which contains
> > the offsets to the pointers in the camel summary file. Then mmap also
>
On Fri, 2006-09-08 at 11:22 -0500, Federico Mena Quintero wrote:
> On Fri, 2006-09-08 at 10:37 +0200, Philip Van Hoof wrote:
> 1. What is the maximum length of those strings? What is the maximum
> length of one message header in the summary file? In the message info
> struct, can y
ny
refactor iterations. But redesigning is imo okay. I just called it
"Agile" as explanation why redesigning and rethinking is important. Not
being afraid of changing things is in my opinion important.
It's a problem the Evolution project is, I think, experiencing. But I'm
powerl
ussion reminds me a lot of similar ones we had over
> in K-town which eventually led to Akonadi, so I couldn't resist to
> pitch it to you a bit. My apologies for hijacking the thread. If you
> have more concrete questions as to the kinds of problems we are facing
> with memory
ther people and companies in the
community who are interested in implementing them. Obviously I will
implement some myself too.
--
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
disks so hard ?
> Thanks !
You can try this patch on evolution-data-server/camel
http://pvanhoof.be/files/camel_folder_summary_with_mmap_fixes11_data_alignment04.diff
But it's not recommended for non-software developers. It's not easy to
get it working unless you have a good kno
\n
> > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
> > Keep-Alive: 300\r\n
> > Connection: keep-alive\r\n
> > Referer: http://10.128.108.84/exchange/\r\n
> > Cookie: sessionid=bab7f8c0-318e-43a2-9869-2e1a654d8eff,0x409;
> > MWC0=DEDFDDDCAF87F9CBA2; MWT0=2A
> > 1E3B4A5C6D2D
a nice
> > to have feature to bring to mobile devices and embedded appliances
> > (which is the focus group of tinymail at this moment).
> >
> > Let me know what you think?
>
> I'll help you as much as possible should you decide to take a closer
> look at e
ibility. I'm interested an
open to adapting the tinymail framework to allow a tool like SyncML to
do such funky stuff.
Please get in touch.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-te
n the evolution
hackers mailing list if you really feel that this has nothing to do with
evolution. Since both projects use Camel, I have a different opinion but
I wouldn't contest yours.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof
stream in-loop.
--
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
Ev
On Sun, 2006-10-22 at 15:41 +0200, Philip Van Hoof wrote:
> In the code I have found no real reason to why this was done in
> separated loops (steps) rather than one step and at the end of the loop,
> free the data already. Especially for the third step (x), which seem to
> consume
address to become a stable enterprise-level GNOME app.
No problem. Yet I hope my experiments might someday be useful for the
Evolution project. Until then, I'll use tinymail as host for them.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
i++) {
data = fetch_data->pdata[i];
g_datalist_clear (&data);
}
g_ptr_array_free (fetch_data, TRUE);
}
if (messages) {
for (i = 0; i < messages->len; i++) {
if (messages->pdata[i])
On Tue, 2006-10-24 at 01:56 +0200, Philip Van Hoof wrote:
> static guint32
> imap_get_uids (
> {
...
> while ((type = camel_imap_command_response (store, &resp, ex)) ==
> CAMEL_IMAP_RESPONSE_UNTAGGED)
> {
...
>
ped and 44% is allocated).
The only API call that makes this incompatible with a normal Camel is
the camel_folder_summary_dump_mmap. If you diff camel-imap-folder.c of
Evolution's Camel with this camel-imap-folder.c of Tinymail's Camel, and
remove those API calls, you'll have a working Camel that doesn&
On Tue, 2006-10-24 at 13:34 +0200, Philip Van Hoof wrote:
> The only API call that makes this incompatible with a normal Camel is
> the camel_folder_summary_dump_mmap. If you diff camel-imap-folder.c of
> Evolution's Camel with this camel-imap-folder.c of Tinymail's Camel, and
ner-nss"
for pc in $mozilla_nss_pcs; do
if $PKG_CONFIG --exists $pc; then
AC_MSG_RESULT($pc)
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
non body part) when it's needed by the E-mail client (lazily).
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
blog: http://pvanhoof.be/blog
___
Evolution-hac
hat Evolution has/had a different scope
(desktop users with plenty of memory and disk-space). So I agree that it
was the best decision to make (to remove the support for partial
retrieving).
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof
:
https://svn.tinymail.org/svn/tinymail/trunk/libtinymail-camel/camel-lite/camel/camel-folder-summary.c
https://svn.tinymail.org/svn/tinymail/trunk/libtinymail-camel/camel-lite/camel/providers/imap/camel-imap-folder.c
If I can assist people with bringing their Camel into this shape, then
please let me
On Thu, 2006-11-16 at 16:13 +0100, Philip Van Hoof wrote:
> I did another round of checking where the memory of Camel is going to in
> tinymail's Camel.
>
> I have also tested its Camel with Evolution with success.
>
> Tinymail's Camel has the following features
On Thu, 2006-11-16 at 11:41 -0500, Joe Shaw wrote:
Hey Joe,
> On Thu, 2006-11-16 at 16:13 +0100, Philip Van Hoof wrote:
> > o. The CamelFolderSummary uses mmap. This significantly reduces memory
> > usage because an mmap is on-demand paged.
>
> Does the
and that this
happens each cancellation.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
blog: http://pvanhoof.be/blog
___
Evolution-hackers mailing list
Evolution-hack
_REC_UNLOCK (imap_folder, cache_lock);
return stream;
errorhander:
CAMEL_SERVICE_REC_UNLOCK (store, connect_lock);
CAMEL_IMAP_FOLDER_REC_UNLOCK (imap_folder, cache_lock);
camel_exception_setv (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
_("Could not find m
b
ps. The locking code of the imap provider is really, really broken or
done in an absolutely insane way.
On Tue, 2007-01-09 at 02:18 +0100, Philip Van Hoof wrote:
> Hi there,
>
> I just finished this one, so there's probably a huge amount of bugs in
> it. I know I should
* callers can grab and release it themselves if they need to run
* multiple commands atomically.) "
Easy == different
On Tue, 2007-01-09 at 03:47 +0100, Philip Van Hoof wrote:
> Bweachrgg. It seems camel_imap_command_response performs an extra
> CAMEL_SERVICE_REC_UNLOCK (store, co
CAMEL_SERVICE_REC_UNLOCK (store, connect_lock);
if (nread <= 0)
handle_freeup (store, nread, ex);
g_free (tag);
if (err)
goto errorhander;
}
if (boundary_len > 0)
it.
I'm for example thinking about making it possible to disabling the
summary support (for example because Evolution, for example, doesn't
need it). It's going in tinymail's camel-lite anyhow .. but I would of
course prefer to have the delta of changes small.
--
Philip Van Hoof, s
About this one and FYI:
On Wed, 2007-01-10 at 20:46 +0100, Philip Van Hoof wrote:
> @@ -386,6 +433,11 @@
> if (pop3_store->cache && fi->uid)
> camel_data_cache_remove(pop3_store->cache,
thing has gone in camel-lite that I
wouldn't allow copyright ownership reassignment for).
Most of these features are still in "this is a hack" status. And they
might not be really useful for a desktop E-mail client (they are crucial
for mobile devices).
--
Philip Van Hoof, softwar
ges, flagged as deleted.
>
> So, question one to get me started is: What function in e-d-s carries
> out message expunging, as distinct from message deletion?
>
> regards,
>
> Seb James
>
>
> ___
> Evolution-hackers mailin
http://bugzilla.gnome.org/show_bug.cgi?id=397130
Please review.
Thanks
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
Evolution-hackers mailing list
Evolution
http://bugzilla.gnome.org/show_bug.cgi?id=397131
Please review.
Thanks
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
Evolution-hackers mailing list
Evolution
s sense to get rid of not-needed information as soon
as possible.
Tinymail uses a forked version of Camel. The local providers haven't had
many changes so your code would probably flow in automatically.
> Thanks again for the explanation you gave, it's very helpful!
No probl
I'm of course planning to get this stuff upstream. But I have to warn
the dreamers.
A lot of it is/was done as a hack. That's because I envision that
someday I actually will switch from using Camel to most likely fejj's
libspruce.
With Camel this was for the last feature, IDLE support, almost un
On Wed, 2007-02-07 at 08:58 -0700, Veerapuram Varadhan wrote:
> On Wed, 2007-02-07 at 11:36 +0100, Philip Van Hoof wrote:
> Of all those features/implementations that you have mentioned so far, I
> could list 2 of them fit the interest of evolution - mmap (without
> summary fo
On Wed, 2007-02-07 at 21:40 +0100, Gilles Dartiguelongue wrote:
> It'd be nice to see the work for IDLE make it to mainline too.
I would like to warn that the work for IDLE pulls nearly each and every
change to the IMAP code with it, as a dependency.
The IDLE work requires changes to dealing with
la, Thunderbird,
> and even Outlook Express.
>
> Thanks for any help,
> David Shifflett
>
>
>
> ___
> Evolution-hackers mailing list
> Evolution-hackers@gnome.org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers
--
Phili
ownload by itself will
consume around 120 MB of RAM, and will most likely fail due to network
timeouts and other such problems (it'll take a while, since Evolution
fetches a ridiculous large amount of headers for each message for
building its summary).
--
Philip Van Hoof, sof
On Thu, 2007-06-07 at 08:25 +0200, Gilles Dartiguelongue wrote:
> Le jeudi 07 juin 2007 à 01:53 +0300, Philip Van Hoof a écrit :
> > Without immediately writing to disk work, the download by itself will
> > consume around 120 MB of RAM, and will most likely fail due to network
&
On Thu, 2007-06-07 at 03:05 -0600, Sankar P wrote:
> On Thu, 2007-06-07 at 10:56 +0300, Philip Van Hoof wrote:
> >
> > It improves the situation by setting your url-string to have the
> > "basic_headers" option. In the imap code of Camel, it will then ask for
>
.g. it could change).
>
> I would probably not be opposed to a CONDSTORE implementation making it
> into upstream camel, tho.
Note that the changes that happened for the CONDSTORE support are very
easy to port to upstream Camel.
If somebody wants to do that and needs my help, he or she c
On Thu, 2007-06-07 at 09:25 -0400, Jeffrey Stedfast wrote:
> On Thu, 2007-06-07 at 10:56 +0300, Philip Van Hoof wrote:
> > The best way is to ask for the ENVELOPE and the remaining info using the
> > normal BODY.PEEK method.
>
> Have you actually ever tested this theory?
let's try to criticise constructive. My apologises for
the negative way of putting that I don't like how imap4 is designed.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
__
On Fri, 2007-06-08 at 20:45 -0400, Jeffrey Stedfast wrote:
> On Fri, 2007-06-08 at 18:34 +0300, Philip Van Hoof wrote:
> > The imap4 project is making things look better, though all in all it's
> > still much of the same (blocking and waiting for results, in stead of
> >
client was not online.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailm
t for SEARCH over multiple folders (IMAP drafts, future)
* Support for server-side SORT
Not planned:
* Pipelining (maybe some day with or in the IMAP4, or with or in
libspruce)
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanho
On Mon, 2007-06-11 at 10:54 +0200, Gilles Dartiguelongue wrote:
> Le lundi 11 juin 2007 à 10:57 +0300, Philip Van Hoof a écrit :
> > * "All" compilation warnings fixed (we usually compile with -Wall and
> >-Werror). Fixing this caused four major bug fixes in
On Mon, 2007-06-11 at 14:48 +0530, Srinivasa Ragavan wrote:
> On Mon, 2007-06-11 at 10:57 +0300, Philip Van Hoof wrote:
> > I'm going to make an overview of camel-lite so that if people read the
> > discussions here, that they know what it's all about.
> >
> >
0:57 +0300, Philip Van Hoof wrote:
> I'm going to make an overview of camel-lite so that if people read the
> discussions here, that they know what it's all about.
>
> Camel-lite is the fork of Camel that Tinymail is using internally right
> now. Camel-lite's code is
nk is)
expected behaviour.
http://tinymail.org/trac/tinymail/changeset/2349?format=diff
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
On Mon, 2007-07-02 at 12:53 -0600, Veerapuram Varadhan wrote:
> On Mon, 2007-07-02 at 20:40 +0200, Philip Van Hoof wrote:
> > I'm not sure but it looks like if any Camel API call that causes a read
> > or a write that isn't wrapped by a CamelOperation, does a blocking rea
rite (camel-object.c:517)
==15153==by 0x419EA69: camel_object_state_write (camel-object.c:1834)
==15153==by 0x4127459: disco_sync (camel-disco-folder.c:282)
==15153==by 0x413663B: camel_folder_sync (camel-folder.c:311)
==15153==by 0x414EB44: store_sync (camel-store.c:690)
--
Philip Van Hoof, so
nal author (I don't know the intention of this code well
enough).
> -Srini
> On Wed, 2007-09-26 at 11:06 +0200, Philip Van Hoof wrote:
> > There's a memory leak in camel-disco-folder.c
> >
> > static int
> > disco_getv(CamelObject *object, CamelException *e
These compilation warnings prevent -Wall -Werror as the configure stage
fails if CFLAGS is set that way.
http://bugzilla.gnome.org/show_bug.cgi?id=483301
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
E support. Although only one IMAP server already
supports this (Isode's Mbox).
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
Evolution-hackers mailing list
Evol
On Sun, 2007-10-07 at 14:15 +0200, Philip Van Hoof wrote:
> Hi there,
> Using this changeset you can follow the changes to camel-lite:
>
> http://tinymail.org/trac/tinymail/changeset/2823
More such commits to Tinymail's camel-lite happened today. Nearly all of
those ar
On Sun, 2007-10-07 at 14:15 +0200, Philip Van Hoof wrote:
> Hi there,
> Using this changeset you can follow the changes to camel-lite:
>
> http://tinymail.org/trac/tinymail/changeset/2823
>
This changeset are a bunch of compilation warnings for Matthew's Base64
onised with
upstream. Most of the changes in that directory are specific and related
to the new features in camel-lite.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
--- Begin Message ---
El lun, 08-10-20
that Novell/Ximian seems to be the copyright holder of all files,
that of course means this organisation makes this decision.
Thanks!
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
__
t process seems like taking time and I have to wait a
> > but before doing anything.
> >
> > -Srini.
> >
> > On Mon, 2007-10-08 at 12:08 +0200, Philip Van Hoof wrote:
> > > Hi there,
> > >
> > > The README.COPYRIGHT of EDS's Camel stat
his one:
http://bugzilla.gnome.org/show_bug.cgi?id=485677
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
Index: libtinymail-camel/camel-lite/camel/camel-mime-util
k, it does work
quite well. At least for this case.
I'm attaching yet another patch that ignores this check.
On Thu, 2007-10-11 at 11:52 +0200, Philip Van Hoof wrote:
> In case iconv does not succeed in decoding for example the Subject
> header, it returns the base64 encoded one. That
too (no need to convince me of that). It
might, however, not be as ideal or harder this way.
Anyway, just thoughts...
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
_
add new tags (user_tags), which is similar to how
user_flags work in Camel. It looks like those are already stored
remotely. I think tags define the colour of the rows in your summary
view (Important, Personal, Work, etc etc).
You'll have to write ui pieces for this too, in Evolution, of course
On Thu, 2007-10-11 at 13:10 -0400, Jeffrey Stedfast wrote:
> On Thu, 2007-10-11 at 17:14 +0200, Philip Van Hoof wrote:
> > On Thu, 2007-10-11 at 10:52 -0400, Jeffrey Stedfast wrote:
> > > I have far better fixes in GMime that need to be ported to Camel.
> > >
> >
On Thu, 2007-10-11 at 12:14 +0200, Philip Van Hoof wrote:
> I also have this one, for example
>
> Subject: =?ISO-2022-JP?B?GyRCJSIlaiUsLUUtRRsoQg==?= (
> =?ISO-2022-JP?B?GyRCITchJiZYISYbKEI=?=)o
> =?ISO-2022-JP?B?GyRCIlwbKEI=?=
> =?ISO-2022-JP?B?G
ol.
I'm for example not sure about the VANISHED reply (and the exact meaning
of that "earlier" parameter).
ps. I added the nice folks at Evolution in CC, as some of these code
warriors are planning to migrate some of newer features in camel-lite to
upstream camel.
--
Philip Van Ho
On Thu, 2007-10-18 at 10:46 +0100, Dave Cridland wrote:
> On Thu Oct 18 00:41:39 2007, Philip Van Hoof wrote:
> > I implemented support for QRESYNC in Tinymail's camel-lite. I never
> > tested this because somehow the MBox copy that the friendly guys at
> > Isode gave me
DONE).
>
> Jeff
>
> On Mon, 2007-10-08 at 00:41 +0200, Philip Van Hoof wrote:
> > On Sun, 2007-10-07 at 14:15 +0200, Philip Van Hoof wrote:
> > > Hi there,
> >
> > > Using this changeset you can follow the changes to camel-lite:
> > >
> > &
ps. Adding Jeffrey in CC as I think he has a good idea how this function
should work.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
Evolution-hac
stream camel and also doing nice things here as well.
Note that I will attend a Lemonade meeting in Munich next month. If
there are any items that I should raise for Evolution, you can let me
know about them.
I of course have a small list myself already.
--
Philip Van Hoof, software developer
On Thu, 2007-10-25 at 11:02 -0400, Matthew Barnes wrote:
> On Thu, 2007-10-25 at 16:45 +0200, Philip Van Hoof wrote:
> >
> > The patch is of course a simple "+ g_ptr_array_free (args, TRUE);" right
> > before the "return out;", right?
> >
> &
that one might think.
-- Note that NOTIFY's RFC is currently in "proposal" state. No IMAP
servers currently implement it (perhaps Sun's beta version does).
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof d
On Thu, 2007-10-25 at 22:25 -0400, Jeffrey Stedfast wrote:
> On Fri, 2007-10-26 at 03:25 +0200, Philip Van Hoof wrote:
> > On Wed, 2007-10-24 at 11:58 -0400, Jeffrey Stedfast wrote:
> > > I took a look at the IDLE implementation last night and felt it went
> >
usually works.
I'm trying to fix this last problem right now, and after that there will
most likely be a few days of testing before I put this in Tinymail's
repository.
> You should simply poll() on the socket descriptors (and a pipe fd used
> for telling the IDLE thread's I/O loo
ne is better:
svn diff http://svn.tinymail.org/svn/tinymail/trunk -r 3126:3128
On Fri, 2007-12-14 at 12:37 +0100, Philip Van Hoof wrote:
> This is a hint-hackish patch that shows the evo developers how to get
> precise progress info while downloading a large message.
>
> I know the Camel
This is a hint-hackish patch that shows the evo developers how to get
precise progress info while downloading a large message.
I know the CamelStreamBuffer hack is kinda ugly ...
http://tinymail.org/trac/tinymail/changeset/3127
--
Philip Van Hoof, freelance software developer
home: me at
tch can be 1:1 applied to upstream Camel.
http://tinymail.org/trac/tinymail/changeset/3135
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://cod
On Sat, 2007-12-15 at 10:18 -0500, Matthew Barnes wrote:
> On Sat, 2007-12-15 at 10:02 -0500, Matthew Barnes wrote:
> > On Sat, 2007-12-15 at 13:53 +0100, Philip Van Hoof wrote:
> > > I don't think just doing a PR_Close is sufficient. I think you need to
> > > do
But feel free to verify my claims, I don't know all such details of
Camel by heart ;)
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be
x27;t exist.
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnom
rrect UI presentation of such
a \NoSelect parent folder (or, placeholder in the folder tree).
Note. An example is the [GMail] folder of Google IMAP. Google's IMAP
server is one of the first times that I saw \NoSelect being actively
used by an IMAP server in a default-ish way.
Evolution will soo
pace:%s\n", str);
g_free (str);
}
first = FALSE;
}
}
g_free (result);
}
On Thu, 2007-12-20 at 14:06 +0100, Philip Van H
plist, so a parameter can be a
"SOMETHING" ("Some setting" "Some more"). hrm ... that's more work :)
On Thu, 2007-12-20 at 21:46 +0100, Philip Van Hoof wrote:
> This is some first piece of code to parse "the other" namespaces
>
> In: imap_connect
On Thu, 2007-12-20 at 21:46 +0100, Philip Van Hoof wrote:
> This is some first piece of code to parse "the other" namespaces
Forget that, imap_parse_namespace_response implements this already and
looks like a fine starting point.
--
Philip Van Hoof, freelance software develope
101 - 200 of 268 matches
Mail list logo
