Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of pepijnnoltes@gmail.com
 designates 209.85.214.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <e87185180dc826866367d7866b75f211.squirrel@ghdev.nl>
References: <e87185180dc826866367d7866b75f211.squirrel@ghdev.nl>
Date: Tue, 28 Jan 2014 19:49:04 +0100
Message-ID: 
 <CAPhv5g8oh5B8tzS3D_AeC0bNsAKD_WKkoeVg5g0ir8k=o8qJzg@mail.gmail.com>
Subject: Re: Event admin patch
From: Pepijn Noltes <pepijnnoltes@gmail.com>
To: celix-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7b874e4c43031504f10c4793

--047d7b874e4c43031504f10c4793
Content-Type: text/plain; charset=ISO-8859-1

Hi Erik,

On Sun, Jan 26, 2014 at 7:55 PM, <erik@jansman.eu> wrote:

> Hello,
>
> I'm sending an updated version of the event admin. I have renamed the
> methods to follow the standards. I have moved the event admin into the
> celix folder like the other subprojects.
>
> Known issues:
> 1: The async sending isn't implemented yet.
> 2: At this moment the event publisher is owner of the memory for the
> event. This is probably not the best solution for the async sending.
>
> I would like to propose a change to the Event admin and move the event
> implementation to the event admin. This would make the event admin owner
> of the memory.
>
> Would this be a good choice or is there another solution?
>

I think this is a good choice. The event admin knows when all sync/async
event handlers have been called and as result when the event can be
deleted.
IMO the event admin API should contain a create for the event and clearly
states that is will also free this event when all event handlers have been
called. The event admin should free the event and its properties, but it
should clearly state that it cannot and will not free complex (e.g.
strings, or pointers to structs) values of the event properties.
For now that is IMO enough, but in eventually we probably also need a
callback to that the owner of the complex values of the event properties
can delete those.

There is of course always another solution ;) Anybody any better/different
ideas?


>
> Regards,
>
> Erik
>
>

--047d7b874e4c43031504f10c4793--