Hi Serge,
Sorry for the delay, I have been Internet-less for the past few days.
Let me try to provide preliminary bits of information here and let's try
to get deeper among further emails.
On Fri, 2013-04-19 at 13:47 +0200, Serge NOEL wrote:
> Hello Julien,
>
> i have some difficulties in my project :
> * How is done association between backend and Openchange.
> In my backend_list_context function, i define 12
> context roles for INBOX, Trash,... by sending back
> contexts_list structure. I that sufficient to inform
> Openchange that it can use my backent for each role or
> do i need to specify backend to use elsewhere ?
It should be.
I would need to double check with latest version, but this code is meant
to be called by emsmdbp_provision.c to auto-provision the user mailbox
on first access. As for now, the code had primarily been developed to
work with the SOGo backend, so it is possible some pieces may be SOGo
specific - which we would need to change to make them more generic.
>
> * Ldap access
> I want to use directly AD/Ldap informations into my
> backend (for Global address book, ...). I need to gain
> informations on Ldap server (i can suppose localhost
> because an Openchange server must be a DC). In this
> case i have to find/store/retreive ldap accounts (for
> searching). Where is the best place to do that ? I can
> use .ldb file to store informations, or retreive
> direct acces from Ldap..
Your LDAP will indeed be - at the moment - on the same machine as there
is no way to separate OpenChange server and backends from Samba4 and
LDAP daemon.
With regards to the LDAP calls, one way to do it - and is as for now the
preferred way - is to use LDB with ldap:// URI. This way, in case at
some point we are able to get OC server on a different host than LDAP
one, then you won't be affected.
The only problem you may encounter at this point is if you are running
Samba4 in single mode. OpenChange server code doesn't yet register
properly with Samba main event loop, and this may be causing some
deadlock when doing LDAP calls form the backend. If you are running
Samba using its forked model, then you won't hit this issue but
debugging will be a little more tricky.
> * Plugin test
> I have forked mapistore_test to be able to test furher
> aspects of my backend. And optionnaly to permit other
> developper to do tests. If i guess well mapistore_test
> is linked with libmapistore, wich in turn can call all
> backend functions.
Correct.
> If i want to test Openchange with real client
> (openchangeclient or Outlook), what are the mandatory
> functions that i need to implement ?
If you intend to test the usability of your backend from a remote client
perspective, I would recommend you to go with mapitest which is our
primary unit test framework. For testing atomic parts of your code, that
should be working.
Now for scenario and complex action testing, here is the thing. When
implementing backend functions for clients, you need to differentiate
between two different modes:
* online mode: that is what openchangeclient and more generally
libmapi provides. The nice thing with it is that you can
incrementally implement your backend calls and *see* the
results. For instance, you could be working first on
implementing backend code supporting 'openchangeclient
--mailbox' (list of mailbox folders).
* cached mode: that is the default Outlook configuration. This
one is more complicated to apprehend in first place, because it
already requires quite a bit of knowledge and require a lot of
non-visible work to be done prior you can see any visible
results. I think I have started to draft some pages on the
tracker to this regards (and for backend development). If not or
if they do not help, then we'll need to provide something
better.
The difference between these 2 modes is how the data is transmitted. In
online mode, specific and dedicated calls will be made. In cached mode
you will have to deal with large buffer transfer which may not be easy
for you to debug in the first place if Outlook complains.
In my opinion, you should start by having your backend to work with
openchangeclient. You will get preliminary results quickly and your OC
server knowledge along with the MAPI one will grow up quickly.
It's difficult to give you a static set of core functions to implement
because in the end they will be almost all required to get a fully
working backend. My opinion is for you to start writing a backend that
can answer commands like openchangeclient --mailbox or openchangeclient
--fetchmail and similar and go through the set of backends functions
incrementally. In the end, for this part, this should be very limited.
When you starts to get some working code, then add the cached mode
behavior required for default Outlook to operate properly.
> * Git branch
> I made a branch dedicated to my job, i try to publish
> it, but it seems that i need write access to the
> repository.
> Sorry for all thoses questions but i hope you can take some times to
> help me.
I am very positive about your effort and really want to help you with
this as much as possible. Feel free to use the list for asking any other
questions. There may be again some delay, but none of your emails should
in the end remained unanswered.
As someone suggested on the list, I would recommend you to start with a
github repository. I have nothing against creating a branch on
openchange git repository too, but I don't have the time to do it right
now and I don't want to be a blocker.
Cheers,
Julien.
>
>
> Le 12/04/2013 15:57, Julien Kerihuel a écrit :
>
> > Hi Serge,
> >
> > On Thu, 2013-04-11 at 12:54 +0200, Serge NOEL wrote:
> > > Firts it seems that we have to create a library with a
> > > mapistore_init_backend entry point. This function initialise a
> > > structure mapistore_backend and call mapistore_backend_register.
> > > This library will be installed in /usr/lib/mapistore_backends (in my
> > > case because i use fhs folder type).
> > > This part is working now (i make a new dummy backend : registering
> > > well )
> > >
> > Ok.
> >
> > > Making make doxygen reveals how backend work, i can get some view of
> > > what to do, but how do we link top-folder and backend ? I am
> > > installing a new virtual machine with Sogo following
> > > http://iabsis.com/ documentation. I will have opportunity to put
> > > triggers on Sogo backend... but seems big work.
> > >
> > > My trouble is due to the fact that Inverse doesn' t comment all
> > > functions. A lot are a bit confuse to me
> > Some time ago, I had started to write openchange mapistore guide for
> > backend development. It may be a bit outdated now and require a bit of
> > updates and polishing, but you should find a preliminary base here
> > (along with other wiki documents)
> >
> > http://tracker.openchange.org/projects/openchange/wiki/MAPIStore_10_Development_Guide
> > > examples:
> > > sogo_backend_create_context I suppose that it serves to initialise
> > > context (can be mail/appointment, ..). But what is expecting
> > > openchange this function to do ?
> > Creating a context is at an upper level than mail/appointment. Roughly
> > speaking, this create context operation happens when you open a
> > root/system mailbox folder (those who are indexed in openchange.ldb
> > database).
> >
> > From your backend perspective, it is a way to initialize private data
> > and perform preliminary operations prior further operations to happen on
> > the destination (backend) folder.
> >
> > > Questions :
> > > * Is there somewhere such a documentation ? I can propose making
> > > this doc.
> > Answered above ;-)
> >
> > > * How to commit my work on openchange repository (in a branch)
> > You can create a git branch and push it on github so your work can be
> > reviewed and merged in / signed-off into master when you start getting
> > results.
> >
> > Btw, what is the backend you are trying to develop?
> >
> > Kind Regards,
> > Julien.
> >
>
--
Julien Kerihuel
[email protected]
OpenChange Project Founder
GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
--
Julien Kerihuel
[email protected]
OpenChange Project Founder
GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
_______________________________________________
devel mailing list
[email protected]
http://mailman.openchange.org/listinfo/devel
