[evolution-patches] Re: ECal bindings in evolution-sharp.

[Mike Kestner <mkestner novell com>]

On Tue, 2005-07-05 at 15:17 +0530, Veerapuram Varadhan wrote:
> Hi,
> 
> Attached patch exposes a limited-edition of ECal APIs through
> evolution-sharp.
> 
> The code is organized into
> 	1) a glue-code in "C".
> 	2) Wrapper classes in C#.
> 
> Glue-code in "C" is mainly used to convert between ical and ecal
> components.

I really don't have any feedback on this code.  I assume you are having
it reviewed by people who know libecal too?  ;-)  

The only suggestion I'd make is that you might want to just have a
libevolutionsharpglue instead of fragmenting it down to just
libecalsharp.  If you guys are going to start actively improving
evo-sharp, you are going to find lots of opportunities to add glue for
ebook I bet, and it seems like a lot of overhead to maintain an
additional library for a few functions there.

We are also starting to generate glue for things like public GObject
fields in GAPI 2.0 and will probably soon be adding glue for virtual
method hookup, so unless you want to have separate generator invocations
for EBook and ECal, you will have to generate all that stuff into a
single glue library.

> Wrapper classes uses the glue-code and creates a
> minimalistic-representation of ECal in C#.  Only, a few fields are
> exposed as of now and can be extended to support many other fields
> later.

The obvious thing that strikes me here is an opportunity to use GAPI to
wrap your glue component, instead of hand wrapping everything.  GAPI and
glib-sharp have functions/classes to map between managed arrays and
G(S)Lists so you could probably avoid a lot of manual wrapper code here
by tuning your glue to be easily wrapped by GAPI.

I see nothing obviously wrong though with the current approach either,
it just leads to a bit more maintained code.

Nicely done.  People are going to love having access to ECal from mono.

-- 
Mike Kestner <mkestner novell com>