[Devel]: Fix datarootdir

Hi,

Attached is a simple patch to the MAILOOK branch that fixes a warning
when using newer versions of autoconf. It should be harmless for older
versions.

Cheers,

Jelmer

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Openchange-devel mailing list
Openchange-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openchange-devel

[Devel]: Fix credentials hack

Hi,

The attached patch fixes libmapi to no longer depend on libpopt and some
of the internal Samba 4 stuff.

Cheers,

Jelmer

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Openchange-devel mailing list
Openchange-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openchange-devel

Re: [Devel]: Fix credentials hack

Jelmer Vernooij wrote:
> The attached patch fixes libmapi to no longer depend on libpopt and some
> of the internal Samba 4 stuff.
Second try, after review by Julien.

Cheers,

Jelmer

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Openchange-devel mailing list
Openchange-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openchange-devel

Re: [Devel]: Fix credentials hack

Jelmer Vernooij wrote:
> The attached patch fixes libmapi to no longer depend on libpopt and some
> of the internal Samba 4 stuff.
Second try, after review by Julien.

Cheers,

Jelmer

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Openchange-devel mailing list
Openchange-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openchange-devel

Re: [Devel]: Fix credentials hack

Jelmer Vernooij wrote:
> Hi,
> 
> The attached patch fixes libmapi to no longer depend on libpopt and some
> of the internal Samba 4 stuff.
Second try, after review by Julien.

Cheers,

Jelmer

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Openchange-devel mailing list
Openchange-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openchange-devel

Re: [Devel]: Fix credentials hack

Patch applied.

Thanks!

On Sun, 2007-03-04 at 17:32 +0100, Jelmer Vernooij wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jelmer Vernooij wrote:
> > The attached patch fixes libmapi to no longer depend on libpopt and some
> > of the internal Samba 4 stuff.
> Second try, after review by Julien.
> 
> Cheers,
> 
> Jelmer

--

-- 
Julien Kerihuel
j.kerihuel <at> openchange.org
OpenChange Project Manager

GnuPG Key: http://jkerihuel.openchange.org/keys/kerihuel_gpg_public.asc

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[Devel]: IDL modifications and torture regression test

I've almost finished to modify the IDL and libmapi so it includes
preliminary changes on the handles management system and makes
mapi_request more generic.

I've also brought a couple of changes to ndr_mapi.c so which fix some
limitations in response decoding. I have not yet commit anything since I
would need your feeling about whether it should be valuable to commit my
current code according to the regression results mentionned below.

Currently I pass the following tests:
- mapi-fetchmail
- mapi-sendmail
- mapi-deletemail
- mapi-folder

I fail against:
- mapi-prop (with deleteprops)
- mapi-message (pull error at some point)

And I'm curious about mapi-sendattach. The test sends a mail to Exchange
but no attached file is provided. Fabien, has it been checked recently?

Regarding the libmapi calls code, we should imo review the size count
system. While I tried to harmonize the whole stuff, there is still 2-3
calls where it is a bit hazardous and needs double check. Currently, we
have either sizeof(field) or hardcoded value or sizeof(type). We should
definitively use the same mechanism so the code remain readable.

Cheers,

Re: [Devel]: IDL modifications and torture regression test

Julien Kerihuel wrote:
> Currently I pass the following tests:
> - mapi-fetchmail
> - mapi-sendmail
> - mapi-deletemail
> - mapi-folder
>
> I fail against:
> - mapi-prop (with deleteprops)
> - mapi-message (pull error at some point)
>
> And I'm curious about mapi-sendattach. The test sends a mail to Exchange
> but no attached file is provided. Fabien, has it been checked recently?
>
>   
Some regression tests are known not to pass since the related call is not
yet well implemented. It includes mapi_message and mapi_prop. mapi_directory
and mapi_table should do fine. Regarding mapi_sendattach, we know there was
a bug regarding an hardcoded value for sending attachment, related to 
the server.
This might come from that.
Any way, we should have a big review along with implementing a 
regression system
with doc to know what is known to pass or not.

Fabien

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your

[Devel]: Current status of the MAILOOK development branch

We are now 1 month and a half before release, and most of the
architecture has been rewritten and is working. The current MAILOOK
branch revision may sound *broken*, but it's just a matter of time
before it runs again properly ;)

In fact we are currently working on several issues:

- MAPI Profiles. 
We are migrating from a repository where parameters needed to be
specified either on command line or in smb.conf (parametric options) to
MAPI profiles stored in ldb database. A first implementation has been
added to the repository but no code has yet been supplied to provision
and manage the profiles database (init,add,delete,modify). This issue
should be fixed within a couple of days. A sample ldif file is provided
in attachment so you can continue using the devel MAILOOK branch until
the provision scripts are added.

- Handle system management
We now have a good understanding of how handles works. We may not
include it in MAILOOK but in the next release when we implement MAPI
call serialization for real. This is for the moment not a high priority
but definitively has a good rank in my TODO list.

- ModifyRecipients
While MAILOOK code was only able to send mails using the To field, we
now know how to set To, Cc, Bcc recipients. I also guess we are close to
figure out the mystic meaning of the current FIXME:modifyrecipients
parametric option and remove it for real. I've added new calls to the
NSPI IDL: NspiResolveNames (already added to the repository) and its
little unicode sister NspiResolveNamesW (which should be commit as soon

Re: [Devel]: Current status of the MAILOOK development branch

I've started the NSPI protocol API upgrade on the MAILOOK branch.
Basically I got ride of the parametric options the user had to provide
in smb.conf. I now have to migrate from nspi_context to mapi profiles
and add/update the mapi profiles ldb code. 

Here is an overview of the parametric options that are now deprecated:
- exchange:organization
- exchange:ou
- exchange:servername
- exchange:username

The first 3 ones are now guessed from nspi_profile scenario.
The last one is set by default to the username credentials related or
can be specified as the last argument or NspiGetMatches.

This makes the API closer to what external developers should deal with.

I've also started the mapi profiles provision script and ejs binding and
I'm currently working on setting up the mapi profiles schema and
attributes so we can add data properly and fetch them easily.

I'll try to commit a first version tonight.

On Sat, 2007-03-10 at 05:04 +0100, Julien Kerihuel wrote:
> We are now 1 month and a half before release, and most of the
> architecture has been rewritten and is working. The current MAILOOK
> branch revision may sound *broken*, but it's just a matter of time
> before it runs again properly ;)
> 
> In fact we are currently working on several issues: