[kforge-dev] Timing of notification of events: problems in relation to apache config generation

[John Bywater]

I'd say that if such disambiguation is required, we should add it in.

However, before we do, alternatives include:

1. As the handler is told which entity will be deleted, it can 
regenerate the whole of the config knowing that it should not provide 
for the entity that will be deleted.

2. The handler is incremental, such that the deleted entity is removed 
from the config (created entities are added to the config). This could 
be implemented in various ways, but we could create and destroy config 
fragments as entities are created and deleted. This might involve a 
compilation of the fragments, and seems more error prone.

Just some thoughts....

John.


Rufus Pollock wrote:

> I was in process of implementing auto re-generation of apache config 
> in response to relevant events such as service creation and deletion. 
> In doing so ran into the following problem:
>
> Apache config building runs off domain. It creates service 
> configuration sections by iterating through service items in the 
> domain. This means:
>
>   onServiceCreate: raised after service created in domain so will 
> create apache config ok
>
>   onServiceDelete: raised **before** service deleted in domain so will 
> **not** create apache config ok (apache config will still be there for 
> a non-existent service). PROBLEM.
>
> This isn't the most serious issue as url for deleted service will 
> simply give an error but it is still not great (it would be really 
> problematic if it were the other way around -- i.e. service creation 
> didn't work). One solution would be to have (as previously suggested) 
> more fine-grained event notification such as beforeServiceDelete and 
> afterServiceDelete but this will add complexity.
>
> ~rufus
>
> _______________________________________________
> kforge-dev mailing list
> kforge-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/kforge-dev
>
>
>