Hi Brad,

On Tue, 2008-03-25 at 15:35 +1100, Brad Hards wrote:
> openchangeclient --ocpf-syntax 
> --ocpf-file=libocpf/examples/sample_appointment.ocpf 
> --ocpf-file=libocpf/examples/common_OLEGUID.ocpf
> libocpf/examples/common_OLEGUID.ocpf:22: OLEGUID invalid

libocpf processes OCPF files sequentially, so you should first include
the common_OLEGUID ocpf file and then the sample_appointment one.
However, if you didn't touch sample_appointment/sample_task examples,
including common_OLEGUID.ocpf should be pointless.

> libocpf/examples/sample_appointment.ocpf:26: OLEGUID invalid
> libocpf/examples/sample_appointment.ocpf:48: Unknown OOM
> libocpf/examples/sample_appointment.ocpf:58: Unknown MNID_ID
> libocpf/examples/sample_appointment.ocpf:66: Unknown MNID_STRING

I've cut most of the warnings cause they are redundant. These errors
shouldn't obviously occur. I'm not yet sure what may be causing them.

When libocpf adds OOM, MNID_ID or MNID_STRING entries from OCPF files,
it relies on mapi_nameid_{OOM,lid,string}_lookup (libmapi/mapi_nameid.c)
These functions check within the auto-generated mapi_nameid_tags[] from
libmapi/mapi_nameid_private.h for a match.

Can you check whether libmapi/mapi_nameid_private.h is correctly
generated and holds OOM, MNID_ID, MNID_STRING values the ocpf file uses?

Did you run make install?

> $ 
> openchangeclient --ocpf-syntax --ocpf-file=libocpf/examples/sample_task.ocpf 
> --ocpf-file=libocpf/examples/common_OLEGUID.ocpf
> libocpf/examples/common_OLEGUID.ocpf:22: OLEGUID invalid
  [...]
> PROPERTIES:
> ===========
>         0x00360003 = PR_SENSITIVITY
>         0x00170003 = PR_IMPORTANCE
>         0x1000001e = PR_BODY
>         0x0e1d001e = PR_NORMALIZED_SUBJECT
>         0x0070001e = PR_CONVERSATION_TOPIC
> 
> NAMED PROPERTIES:
> =================
> 
>         OOM:
>         ----
> 
>         MNID_ID:
>         --------
> 
>         MNID_STRING:
>         ------------
>     OCPF Syntax              : MAPI_E_SUCCESS (0x0)
> 
> Is this expected? 

Yes. The ocpf file above has both properties and named properties. While
named properties are skipped (not the expected behavior), known
properties are anyway stored and libocpf can process the message.

I'll give a try whether libocpf keeps processing the message if there's
neither known nor named properties. 

> When I actually try to send them, the task example appears to work, but the 
> appointment example fails:
> openchangeclient --ocpf-sender 
> --ocpf-file=libocpf/examples/sample_appointment.ocpf 
> --ocpf-file=libocpf/examples/common_OLEGUID.ocpf
>     OCPF Sender              : MAPI_E_INVALID_PARAMETER (0x80070057)
> 
> Any suggestions?

It is highly possible appointment requires named properties to create a
valid appointment while task can create an entry with known properties
only. 

If we solve the ocpf issue you mentioned first, I'm confident it will
solve all the problems you encountered.

Cheers,
Julien.

-- 
Julien Kerihuel
[EMAIL PROTECTED]
OpenChange Project Manager

GPG Fingerprint: 0B55 783D A781 6329 108A  B609 7EF6 FE11 A35F 1F79

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
devel mailing list
[email protected]
http://mailman.openchange.org/listinfo/devel

Reply via email to