headers
Julien Kerihuel | 1 Nov 2007 02:19
Favicon
Gravatar

Re: [openchange]MAPI_E_INVALID_PARAMETER with exchange 2007

Hi Christophe,

I've updated mapiprofile to make debugging easier (--dump-data option
added).

Can you:
        1. update to the latest openchange revision (r308 at the time I
        write this email)
        2. run mapiprofile --create again with --dump-data
        3. provide the command-line you have been using 
        4. provide the relevant part of the output dump

Feel free to remove any sensitive information you need before posting
but please do not omit to supply the NSPI function where the error
occurs.

Cheers,
Julien.

On Wed, 2007-10-31 at 07:01 +0000, christophe choquet wrote:
> Hi,
> 
> I'am using the latest libMAPI svn and have patched it to enable logs.
> The loging process to an exchange server (8.0.685.0) looks ok, as I
> can see my user profile properties in the logs (organization and
> office).
> 
> However, there is a query to find the exchange server, and it looks it
> fails:
> (The company name has been hidden)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sumit Bose | 1 Nov 2007 14:56

Re: [openchange]OpenChange MAPI Library 0.6 (HOLODECK) released

Hi,

2007/10/31, Julien Kerihuel <j.kerihuel <at> openchange.org>:
> OpenChange MAPI Library 0.6 (HOLODECK) released
>

I have build rpm packages for current opensuse and fedora releases
with the opensuse build service. You can find them under
http://download.opensuse.org/repositories/home:/sbose/ together with a
current samba4 package.

Any suggestions for better packaging are welcome.

bye,
Sumit
Permalink | Reply | 1 comment |
headers
Julien Kerihuel | 1 Nov 2007 18:17
Favicon
Gravatar

Re: [openchange]Porting OpenChange Exchange provider to Tinymail

Hello Philip,

Now we've released libmapi-0.6 HOLODECK, I can finally get back to you
-- as promised -- and continue this discussion. 

1. Gnome Evolution and openchange:
        You may have already noticed the EXCHANGE-MAPI-BRANCH on
        Evolution repository:
        http://svn.gnome.org/viewvc/evolution/branches/EXCHANGE_MAPI_BRANCH/ 
        I was wondering if you had been in touch with the developers
        working on this branch and if bridging the gap would make sense?

2. Samba4, OpenChange and ARM:
        I remember a presentation Alexander Bokovoy gave at SambaXP
        about embedding Samba4 and just have found his PDF presentation
        again:
        http://sambaxp.org/uploads/media/10_-_alexander_bokovoy_-_samba_team_-_embedding_samba4.pdf
        Have you been in touch with ab and do you have more information
        about the current state of development of his researches?

On Sat, 2007-10-06 at 12:57 +0200, Philip Van Hoof wrote:
> On Sat, 2007-10-06 at 04:40 +0200, Julien Kerihuel wrote:
> > On Thu, 2007-10-04 at 20:45 +0200, Philip Van Hoof wrote:
> 
> > The only issue at the moment is that we are trying to focus on getting
> > the 0.6 release out the door[1] in the next couple of weeks. So, much as
> > we would like to look at what you've done there is a very real danger it
> > would be far too interesting :-) As you can see from the list of items
> > we are rapidly stabilizing the library in ways that should make it
> > easier for people like you to work with it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Shearer | 1 Nov 2007 19:03
Favicon

Re: [openchange]Porting OpenChange Exchange provider to Tinymail

[not to tinymail-devel, which was in the original Cc]

On Sat, Oct 06, 2007 at 12:57:03PM +0200, Philip Van Hoof wrote:

> The current users of Tinymail are not yet planning to ship with Samba4
> libraries on their devices, so there's no rush yet. But in future I
> think it would be a very interesting something to support, on mobiles.

The embedded case is another reason why we need to know exactly which
Samba4 libraries are needed by OpenChange, and then which functions
within those libraries are actually used. In the ideal case we would
have only those libraries used, and only functions within those
libraries that are used. I don't expect that to ever be completely the
case, but we need information in order to assess where we stand, and
then, potentially, have a discussion with the Samba4 team.

If anyone wants to volunteer to do this analysis, that would be
wonderful :-)

--

-- 
Dan Shearer
dan <at> shearer.org
Permalink | Reply | 0 comments |
headers
Philip Van Hoof | 2 Nov 2007 12:49
Picon
Gravatar

Re: [openchange][devel] Porting OpenChange Exchange provider to Tinymail

On Thu, 2007-11-01 at 18:17 +0100, Julien Kerihuel wrote:

> Now we've released libmapi-0.6 HOLODECK, I can finally get back to you
> -- as promised -- and continue this discussion. 

Hey Julien,

> 1. Gnome Evolution and openchange:
>         You may have already noticed the EXCHANGE-MAPI-BRANCH on
>         Evolution repository:
>         http://svn.gnome.org/viewvc/evolution/branches/EXCHANGE_MAPI_BRANCH/ 
>         I was wondering if you had been in touch with the developers
>         working on this branch and if bridging the gap would make sense?

I'm aware of the branch but we (the Evolution team working on this and
me) have not yet discussed how we can close the gap for Tinymail's
camel-lite and this branch in Evolution's Camel pieces.

However. The changes that are required are small and I can probably copy
the exchange Camel provider over to camel-lite and maintain this work.

I'm waiting for them to stabilise a little bit.

Me and Matthew Barnes have also started migrating certain features from
Camel-lite into upstream Camel, closing the gap further too. Although
this effort will most likely not touch the parts that right now make the
changes required (mostly the CamelFolderSummary pieces, as the summary
is mmap()ed in stead of read() piece by piece in Camel-lite).

I understood the CamelFolderSummary changes (the mmap work) ain't going
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien Kerihuel | 6 Nov 2007 08:31
Favicon
Gravatar

Re: [openchange]OpenChange MAPI Library 0.6 (HOLODECK) released

Hi Sumit,

Thanks for the good job!

I would anyway have some comments based on previous
attempts/experiences:

1. You should define an arbitrary samba4 installation path
(e.g. /usr/local/samba4) so it doesn't clash with samba3 installation
from the distribution.

2. Depending on how the Samba4 will be used for (openchange or really
samba), it may be worthwhile to produce a light samba4 package with a
very limited set of files: libraries, headers and common tools (ndrdump,
smbtorture, pidl).

Cheers,
Julien.

On Thu, 2007-11-01 at 14:56 +0100, Sumit Bose wrote:
> Hi,
> 
> 2007/10/31, Julien Kerihuel <j.kerihuel <at> openchange.org>:
> > OpenChange MAPI Library 0.6 (HOLODECK) released
> >
> 
> I have build rpm packages for current opensuse and fedora releases
> with the opensuse build service. You can find them under
> http://download.opensuse.org/repositories/home:/sbose/ together with a
> current samba4 package.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Kretlow | 9 Nov 2007 01:42
Picon

[openchange]Perl-Bindings

Hello everyone,

I am quite new to the openchange project/stuff. I like to extend an own email
client written in Perl with MAPI capabilities and appreciated it very much that
a MAPI Perl modul is already available. But now I recognized, that the bindings
are still incomplete, especially I need the feature to fetch attachments. Does
anyone in the community already completed the perl module/lib with at least this
feature? I am not familar with SWIG.

Thanx for any suggestions!
Mike Kretlow
Permalink | Reply | 3 comments |
headers
Mike Kretlow | 9 Nov 2007 12:38
Picon

Re: [openchange]Perl-Bindings

Hello *,

after reading a little bit SWIG docu and looking into the existing mapi.i it was
an easy task to add
the additional functions I needed/mentioned. 

Cheers, Mike

On 09.11.2007 at 01:42 Mike Kretlow wrote:

>Hello everyone,
>
>I am quite new to the openchange project/stuff. I like to extend an own
>email
>client written in Perl with MAPI capabilities and appreciated it very much
>that
>a MAPI Perl modul is already available. But now I recognized, that the
>bindings
>are still incomplete, especially I need the feature to fetch attachments.
>Does
>anyone in the community already completed the perl module/lib with at
>least this
>feature? I am not familar with SWIG.
>
>Thanx for any suggestions!
>Mike Kretlow
>
>
>_______________________________________________
>devel mailing list
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ali Mdidech | 9 Nov 2007 13:32
Favicon

Re: [openchange]Perl-Bindings

Hi Mike,

It would be really useful for the community if you decide to submit your
patch through http://trac.openchange.org/
Providing a full perl bindings is one of our wishes and we hope to get some
folks interested on that.

Cheers,

On Fri, 09 Nov 2007 12:38:21 +0100, "Mike Kretlow" <mkretlow <at> gmx.net>
wrote:
> Hello *,
> 
> after reading a little bit SWIG docu and looking into the existing mapi.i
> it was
> an easy task to add
> the additional functions I needed/mentioned.
> 
> Cheers, Mike
> 
> 
> On 09.11.2007 at 01:42 Mike Kretlow wrote:
> 
>>Hello everyone,
>>
>>I am quite new to the openchange project/stuff. I like to extend an own
>>email
>>client written in Perl with MAPI capabilities and appreciated it very
> much
>>that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan (metze) Metzmacher | 9 Nov 2007 13:35
Picon
Favicon

Re: [LDB][PATCH] Make LDB fail on invalid baseDN


Andrew Bartlett schrieb:
> When searching in LDB, we don't currently ensure that the base DN
> actually exists.  With this patch we will - therefore returning correct
> errors to clients, and matching behaviour with LDAP (making support for
> an LDAP backend easier, as the same error paths apply). 
> 
> The main issue with this patch so far is that places where we expect
> this non-standard behaviour.  Many I've removed for the LDAP backend,
> but I still need to work on SPOOLSS and WINS.

There's also the samba3 group mapping code and the OpenChange code.

And I think there're lot more callers within samba which check for
res->count == 0 instead of NO_SUCH_OBJECT, do a grep 'res->count' */*.c
*/*/*.c */*/*/*.c. In most cases this are BASE searches...

I think we would be good to explict enable this new behavior via
an  <at> OPTIONS object. And only do for our samdb.ldb.

> The main issue I can see with this patch is that it's racy - it is
> theoretically possible for the base DN to exist, and be deleted before
> we finish the search, as it's just a 'pre-check'.  

Doesn't ltdb_[un]lock_read() handle this.

metze
Permalink | Reply | 2 comments |

Gmane