Re: [otlkcon-devel] development environment - RE: Status?

2009-07-22 Thread Kervin Pierre
This is very interesting.  I hadn't noticed that.

These providers have been around in one form or the other for  at least 10 
years now, first distributed with the MAPI Provider book.

We could never use them though because there was no explicit license attached 
to the source.

But with their inclusion on  Codeplex and explicit license we can now probably 
utilize those.  I'll look into this further.

Best regards,
Kervin


From: g...@novadsp.com [mailto:g...@novadsp.com]
Sent: Wednesday, July 22, 2009 2:32 PM
To: Kervin Pierre
Cc: otlkcon-devel@lists.sourceforge.net
Subject: Re: development environment - RE: [otlkcon-devel] Status?

K, seen these? http://www.codeplex.com/OutlookMAPISamples

Kervin Pierre wrote:
You won't need Exchange, so that should help simplify the environment.  You 
won't need to inspect packets either.  You will need to inspect assembly.  Are 
you familiar with MAPI internals at all?  Or IDA Pro and Assembly Language?

I really only ever used a CalDAV server for testing.  We can use Bedework ( 
http://bedework.com/ ) for this.

If you plan on working on migrating the datalayer to C#, then you won't need a 
server at all.  All the testing can be done locally.

If you plan to work on shared folders support then you will need IDA Pro and 
lots, and lots of patience :)

Unfortunately, there isn't much documentation.  But I will be happy to answer 
any questions you may have.

 The role of the datalayer is to save MAPI data.  This is what saves 
appointments and messages to the disk.  It is only used by a very small number 
of interfaces.  Actually IMAPIProp 
(http://otlkcon.svn.sourceforge.net/viewvc/otlkcon/trunk/otlkcon/opncon/O_IProp.cpp?view=markup
 ) and IMAPITable being the biggest consumers.  Currently, it uses an SQLite 
database.  We should move this to SQL Server Compact for better locking, 
application transaction model and more support for platform database 
abstraction features.

Again, feel free to ask as many questions as you'd like.  I will try to clarify 
things as best as I can.

Best regards,
Kervin

--
___
otlkcon-devel mailing list
otlkcon-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/otlkcon-devel


Re: [otlkcon-devel] development environment - RE: Status?

2009-07-22 Thread g...@novadsp.com

K, seen these? http://www.codeplex.com/OutlookMAPISamples

Kervin Pierre wrote:


You won't need Exchange, so that should help simplify the 
environment.  You won't need to inspect packets either.  You will need 
to inspect assembly.  Are you familiar with MAPI internals at all?  Or 
IDA Pro and Assembly Language?


 

I really only ever used a CalDAV server for testing.  We can use 
Bedework ( http://bedework.com/ ) for this.


 

If you plan on working on migrating the datalayer to C#, then you 
won't need a server at all.  All the testing can be done locally.


 

If you plan to work on shared folders support then you will need IDA 
Pro and lots, and lots of patience J


 

Unfortunately, there isn't much documentation.  But I will be happy to 
answer any questions you may have.


 

 The role of the datalayer is to save MAPI data.  This is what saves 
appointments and messages to the disk.  It is only used by a very 
small number of interfaces.  Actually IMAPIProp 
(http://otlkcon.svn.sourceforge.net/viewvc/otlkcon/trunk/otlkcon/opncon/O_IProp.cpp?view=markup 
) and IMAPITable being the biggest consumers.  Currently, it uses an 
SQLite database.  We should move this to SQL Server Compact for better 
locking, application transaction model and more support for platform 
database abstraction features.


 

Again, feel free to ask as many questions as you'd like.  I will try 
to clarify things as best as I can.


 


Best regards,

Kervin


--
___
otlkcon-devel mailing list
otlkcon-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/otlkcon-devel


Re: [otlkcon-devel] development environment - RE: Status?

2009-07-22 Thread g...@novadsp.com

Hello all,

Further searching around the Unix/MAPI theme shows Evolution has covered 
a lot of ground.


See here for their project status: http://www.go-evolution.org/MAPIProvider

This matrix is interesting too: 
http://www.go-evolution.org/MAPIProvider/vsOWA


Jerry.


Kervin Pierre wrote:


This is very interesting.  I hadn't noticed that.

 

These providers have been around in one form or the other for  at 
least 10 years now, first distributed with the MAPI Provider book.


 

We could never use them though because there was no explicit license 
attached to the source.


 

But with their inclusion on  Codeplex and explicit license we can now 
probably utilize those.  I'll look into this further.


 


Best regards,

Kervin

 

 


*From:* g...@novadsp.com [mailto:g...@novadsp.com]
*Sent:* Wednesday, July 22, 2009 2:32 PM
*To:* Kervin Pierre
*Cc:* otlkcon-devel@lists.sourceforge.net
*Subject:* Re: development environment - RE: [otlkcon-devel] Status?

 


K, seen these? http://www.codeplex.com/OutlookMAPISamples

Kervin Pierre wrote:

You won't need Exchange, so that should help simplify the 
environment.  You won't need to inspect packets either.  You will need 
to inspect assembly.  Are you familiar with MAPI internals at all?  Or 
IDA Pro and Assembly Language?


 

I really only ever used a CalDAV server for testing.  We can use 
Bedework ( http://bedework.com/ ) for this.


 

If you plan on working on migrating the datalayer to C#, then you 
won't need a server at all.  All the testing can be done locally.


 

If you plan to work on shared folders support then you will need IDA 
Pro and lots, and lots of patience J


 

Unfortunately, there isn't much documentation.  But I will be happy to 
answer any questions you may have.


 

 The role of the datalayer is to save MAPI data.  This is what saves 
appointments and messages to the disk.  It is only used by a very 
small number of interfaces.  Actually IMAPIProp 
(http://otlkcon.svn.sourceforge.net/viewvc/otlkcon/trunk/otlkcon/opncon/O_IProp.cpp?view=markup 
) and IMAPITable being the biggest consumers.  Currently, it uses an 
SQLite database.  We should move this to SQL Server Compact for better 
locking, application transaction model and more support for platform 
database abstraction features.


 

Again, feel free to ask as many questions as you'd like.  I will try 
to clarify things as best as I can.


 


Best regards,

Kervin

 

--
___
otlkcon-devel mailing list
otlkcon-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/otlkcon-devel