Milan Crha | 6 Dec 19:26 2011
Picon

[openchange]Question on SPropValue vs. mapi_SPropValue

	Hi,
maybe a newbie question, but I never understood why there is SPropValue
and mapi_SPropValue, or at least those unions for values. I didn't think
of it much till now, as it seems to me that mapi_SPropValue(_CTR) is
just an overhead, as the inner unions (those _CTR) should be identical
between these two structures and having everything in defined twice is
sometimes confusing.

Can anyone correct me and tell me what the reason was, please?
	Thanks in advance and bye,
	Milan
Wolfgang Sourdeau | 6 Dec 20:04 2011
Picon

Re: [openchange]Question on SPropValue vs. mapi_SPropValue

Le 11-12-06 13:26, Milan Crha a écrit :
> 	Hi,
> maybe a newbie question, but I never understood why there is SPropValue
> and mapi_SPropValue, or at least those unions for values. I didn't think
> of it much till now, as it seems to me that mapi_SPropValue(_CTR) is
> just an overhead, as the inner unions (those _CTR) should be identical
> between these two structures and having everything in defined twice is
> sometimes confusing.
>
> Can anyone correct me and tell me what the reason was, please?
> 	Thanks in advance and bye,

Hi Milan,

Those structures correspond to different representations of the same 
datatypes, depending on where they are rendered or parsed in the protocol.

For example, a PT_BINARY property will always be rendered as a 
mapi_SPropValue when transferred via a RopGetProperties or a 
RopQueryRows but as a SPropValue when transferred via the stream ROPs or 
the FastTransfer ROPs.

Basically, the mapi_ ones are made to not take more than 32767 bytes 
while the non-mapi ones can be 2^32-1 bytes long, this does not apply to 
small values but will apply to string, binary and array values...

Cheers,

Wolfgang
(Continue reading)

Jelmer Vernooij | 6 Dec 20:41 2011

[openchange]Call for testing: MAPI support in fetchmail

There now is a fetchmail preview release available with support for 
MAPI, through OpenChange, and based on the work that Yangyan Li did as 
part of the Google Summer of Code some time ago. Fetchmail is currently 
looking for reports on whether or not the MAPI integration works, so if 
you try it out, please let them know if it works or doesn't work for you.

You can download the prerelease as source here:

http://www.dt.e-technik.uni-dortmund.de/~ma/fetchmail/ 
<http://www.dt.e-technik.uni-dortmund.de/%7Ema/fetchmail/>

If you're an Ubuntu user, you can also install fetchmail with MAPI 
enabled from the OpenChange daily build PPA:

$ apt-add-repository
$ apt-get install fetchmail

(or see https://code.launchpad.net/~openchange/+archive/daily)

Cheers,

Jelmer
Milan Crha | 7 Dec 09:41 2011
Picon

Re: [openchange]Question on SPropValue vs. mapi_SPropValue

On Tue, 2011-12-06 at 14:04 -0500, Wolfgang Sourdeau wrote:
> Those structures correspond to different representations of the same 
> datatypes, depending on where they are rendered or parsed in the protocol.
> 
> For example, a PT_BINARY property will always be rendered as a 
> mapi_SPropValue when transferred via a RopGetProperties or a 
> RopQueryRows but as a SPropValue when transferred via the stream ROPs or 
> the FastTransfer ROPs.
> 
> Basically, the mapi_ ones are made to not take more than 32767 bytes 
> while the non-mapi ones can be 2^32-1 bytes long, this does not apply to 
> small values but will apply to string, binary and array values...

	Hi,
thanks for the answer. I see that GetProps takes struct SPropValue **
and GetPropsAll takes struct mapi_SPropValue_array *, still, if I recall
correctly, both will fail with PidTagBody or PidTagHtml larger than 4KB.
It's quite long time I played with this, thus it's possible I'm wrong
here.

Anyway, OK, let's keep there mapi_SPropValue and SPropValue structs, but
join mapi_SPropValue_CTR and SPropValue_CTR into one structure seems to
me as a good step, feel free to call it a cleanup. I see that MSDN
doesn't distinguish between these two [1], though they have it done
slightly differently with compare to OpenChange. (Some values are
probably stored as PT_PTR, to avoid circular dependencies, seems to me).
	Bye,
	Milan

[1] http://msdn.microsoft.com/en-us/library/cc815896.aspx
(Continue reading)

Julien Kerihuel | 7 Dec 11:34 2011

Re: [openchange]Question on SPropValue vs. mapi_SPropValue

On Wed, 2011-12-07 at 09:41 +0100, Milan Crha wrote:
> 	Hi,
> thanks for the answer. I see that GetProps takes struct SPropValue **
> and GetPropsAll takes struct mapi_SPropValue_array *, still, if I recall
> correctly, both will fail with PidTagBody or PidTagHtml larger than 4KB.
> It's quite long time I played with this, thus it's possible I'm wrong
> here.

Hi Milan,

It will return MAPI_E_NO_ENOUGH_RESOURCES for property's content larger
than 32Kb.

> Anyway, OK, let's keep there mapi_SPropValue and SPropValue structs, but
> join mapi_SPropValue_CTR and SPropValue_CTR into one structure seems to
> me as a good step, feel free to call it a cleanup.

SPropValue was primarily introduced in OpenChange when we were
implemented the NSPI protocol.

When we implemented MAPI, we noted the union size was different for some
of its attribute. Joining is not an option since it wouldn't match for
both NSPI and EMSMDB protocols and would lead in incorrect crafted
packets to be generated by the NDR layer.

Cheers,
Julien.

--

-- 
Julien Kerihuel
(Continue reading)

Brad Hards | 7 Dec 20:40 2011
Picon

Re: [openchange]Question on SPropValue vs. mapi_SPropValue

On Wed, 7 Dec 2011 07:41:46 PM Milan Crha wrote:
> Anyway, OK, let's keep there mapi_SPropValue and SPropValue structs, but
> join mapi_SPropValue_CTR and SPropValue_CTR into one structure seems to
> me as a good step, feel free to call it a cleanup. I see that MSDN
> doesn't distinguish between these two [1], though they have it done
> slightly differently with compare to OpenChange. (Some values are
> probably stored as PT_PTR, to avoid circular dependencies, seems to me).
This isn't as simple as it might look. IIRC, there are differences to work-
around limitations in what PIDL can handle. That is, these differences are used 
to handle the serialization from the wire.

Brad
Stojan Rancic (Iprom | 27 Dec 22:31 2011
Picon

[openchange]SoGo / Openchange plugin compile failure

Hello,

I'm following the OC/SoGo appliance installation script

(http://tracker.openchange.org/projects/openchange/wiki/HowTo_build_your_own_OpenChangeSOGo_appliance) 
and I'm having issues when compiling the SOGo OpenChange plugin.

I get the error below. If I take a look at time.h I can see all the 
errors occur with 'bool' usage..

I'm compiling this on Debian/Stable (6.0.3) .

Making all for bundle SOGoBackend...
  Creating SOGoBackend.MAPIStore/....
  Compiling file MAPIApplication.m ...
  Compiling file MAPIStoreActiveTables.m ...
  Compiling file MAPIStoreAuthenticator.m ...
  Compiling file MAPIStoreMapping.m ...
  Compiling file MAPIStoreMIME.m ...
  Compiling file MAPIStoreTypes.m ...
  Compiling file MAPIStorePropertySelectors.m ...
  Compiling file MAPIStoreSamDBUtils.m ...
  Compiling file SOGoMAPIVolatileMessage.m ...
  Compiling file SOGoMAPIFSFolder.m ...
In file included from SOGoMAPIFSFolder.m:43:
/usr/local/samba/include/util/time.h:83: error: expected ‘=’, ‘,’, ‘;’, 
‘asm’ or ‘__attribute__’ before ‘null_time’
/usr/local/samba/include/util/time.h:88: error: expected ‘=’, ‘,’, ‘;’, 
‘asm’ or ‘__attribute__’ before ‘null_nttime’
/usr/local/samba/include/util/time.h:132: error: expected declaration 
(Continue reading)


Gmane