headers
Alois Schloegl | 3 Oct 2011 10:13
Picon
Favicon

Re: [openchange]mapidump_contact does sometimes not finish

On 09/29/11 11:43, Brad Hards wrote:
> On Thursday 29 September 2011 19:37:38 Alois Schloegl wrote:
>> It seems that there is a synchronization issue, when the server is
>> internally updating and openchange tries to read the data from the
>> server at the same time.
> That seems unlikely - there is quite sophisticated locking on the Exchange
> database side. Its not impossible though.
>
>> This raises the following questions:
>> 1) Are You aware of this issue ?
> I am personally not.
>
>> 2) I'm using the above test to check for the consistency of the result.
>> Is there are better solution or workaround for this problem ?
> I don't really understand what you're seeing, so I can't advise further.

Here is a more detailed explanation. The "contacts" in public folder of 
an exchange server are exported with openchangeclient (*), using

openchangeclient --pf --fetch-items=Contact --folder "Contacts"> testocx.txt

The first two data sets of the resulting file are attached (**). First 
line in file testocx.txt (i.e. "MAILBOX (1586 messages)"
contains the number of exported data sets. (The term MAILBOX is 
misleading, but irrelevant)   	

Then, one gets the individual data sets, each starting with
    |== <CARD_NAME> ==| : <ID>

Usually, the number indicated in the first line "MAILBOX (1586
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brad Hards | 3 Oct 2011 10:30

Re: [openchange]mapidump_contact does sometimes not finish

On Monday 03 October 2011 19:13:30 Alois Schloegl wrote:
> (*) patch_unicode+keywords.diff: the function function mapidump_contact 
> in libmapi/mapidump.c is actually patched, it incorporates a field 
> separator 0x1e, in order to avoid escaping of special characters within 
> each field.
Maybe someone else can make more sense of this, but I'm more confused than 
before.  Possibly it doesn't help that I can't read the perl script.

Is the problem that you just don't like the formatting of mapidump_contact? I 
think you're possibly expecting too much of openchangeclient...

Why are you reverting changes to the version of samba? Which part of the patch 
relates the problem you're trying to describe?

Brad
Permalink | Reply | 1 comment |
headers
Alois Schloegl | 3 Oct 2011 11:50
Picon
Favicon

Re: [openchange]mapidump_contact does sometimes not finish

On 10/03/11 10:30, Brad Hards wrote:
> On Monday 03 October 2011 19:13:30 Alois Schloegl wrote:
>> (*) patch_unicode+keywords.diff: the function function mapidump_contact
>> in libmapi/mapidump.c is actually patched, it incorporates a field
>> separator 0x1e, in order to avoid escaping of special characters within
>> each field.
> Maybe someone else can make more sense of this, but I'm more confused than
> before.  Possibly it doesn't help that I can't read the perl script.

The purpose of this script is to test whether the number in the first 
line matches the number of data records, if not it reports a warning.

Of course, one could use a number of other tools, for testing this 
issue. Pick any, you feel comfortable with.

>
> Is the problem that you just don't like the formatting of mapidump_contact? I
> think you're possibly expecting too much of openchangeclient...

I've included the patch because I use a number of additional fields in 
mapidump_contact and I'm not sure whether this might affect the issue.

The reason for using a different line separator is, that some field 
values can have multiple lines, this easily confuses my parser of the 
dump file. Escaping of special characters (like <line feed>, <new line>, 
etc) seemed to be more complicated than the present solution.

Ideally, there would be an interface to SQL, or at least a CSV export.

>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Milan Crha | 6 Oct 2011 21:30
Picon
Favicon

[openchange]Decrease connection timeout and cancel requests in libmapi

	Hi,
I'm not much familiar with this low-level API, neither whether it's
available within libmapi API or through it anyhow, but I would like to
ask whether it's possible to:
a) decrease timeout interval for connection polling
b) cancel ongoing requests (also down to a connection level)

The first might be useful for quicker notice of lost connection, because
I believe that 30 seconds of poll waiting is enough, while libmapi
requests take significantly longer for me (I never gave it more than
couple minutes and then killed the process myself anyway).

The second is for cancel requests by a user. Say he/she sees fetching
too slow and decides to quit/cancel it. Right now the application
(evolution) is waiting til the fetch is done (or for a) in particular
cases), while there might be a wait to force cancel on either polling or
fetching at all (I'm thinking also about XFer calls).

Do you know whether there's a solution for this in libmapi and how to do
that, please?
	Thanks and bye,
	Milan
Permalink | Reply | 0 comments |
headers
Milan Crha | 26 Oct 2011 12:49
Picon
Favicon

[openchange]Cannod add item to an empty SPropTagArray

	Hi,
before I file a bug I would like to ask whether I'm missing anything
here. I thought I'll use this code snippet:

-------------------------------------------------------------------
   struct SPropTagArray *array;

   array = talloc_zero (mem_ctx, struct SPropTagArray);
   if (a)
      SPropTagArray_add (mem_ctx, array, PidTag...);
   if (b)
      SPropTagArray_add (mem_ctx, array, PidTag...);

-------------------------------------------------------------------

but it doesn't work, my PidTag is not added. I checked the content of
SPropTagArray_add() and it tests whether the array is not empty, and when
it is it claims the array is invalid. I do not think it's an issue, just
the opposite, as it's quite useful to be able to create an empty array
and fill it later on demand, rather then workaround it like this:

-------------------------------------------------------------------
   struct SPropTagArray *array = NULL;

   #define add(x) {\
      if (!array) \
         array = set_SPropTagArray (mem_ctx, 0x1, x); \
      else \
         SPropTagArray_add (mem_ctx, array, x); } \
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kristen Eisenberg | 29 Oct 2011 13:53
Picon
Favicon

[openchange]newbie, introduction and questions

Hi,


I'm new to openchange and trying to get into extending openchange for
our needs. We are using openchange for exporting calender and address
book information from the exchange server, in order to make this
information available to our mac and linux users. I'm trying to
implement the following features:

- extract the e-mail address from contact folders
(this is already working, using the patch from
http://mailman.openchange.org/pipermail/devel/2011-March/005356.html
). It might need some clean up, specifically the value codes should move
somewhere else. Has anyone some recommendations about this ?

Kristen Eisenberg
Billige Flüge
Marketing GmbH
Emanuelstr. 3,
10317 Berlin
Deutschland
Telefon: +49 (33)
5310967
Email:
utebachmeier at
gmail.com
Site:
http://flug.airego.de - Billige Flüge vergleichen
_______________________________________________
devel mailing list
devel <at> lists.openchange.org
http://mailman.openchange.org/listinfo/devel
Permalink | Reply | 0 comments |

Gmane