2) create an avalon emulation layer for the legacy components that would allow avalon components to run unmodified [this allows users to have a smooth migration path and no immediate impact on their development/mainteinance costs]
Both sound very good assuming someone is able and willing to do the work. But I understand you and Pier would have (or already have had) energy to contribute.
I had quite a lot of time to spare on it as my employer (as the members of the PMC know) asked me to lay down the groundwork for our next back-end platform. And basically, I had to come up with a framework satisfying certain requirements.
With the invaluable help of Stefano and his vision on blocks, I'm pretty close to a release of the code, and if this community at large wants to see more of the implementation and what I'm talking about, just speak up, and I'll get a formal authorization from my manager (until now, confirmation is only verbal).
I am sorry for those who are not on the PMC (on the PMC I keep a more detailed status update, and occasionally post some code snapshots), but it's not _MY_ code. Yes, I wrote it, but it's my EMPLOYER's code, and legally I personally don't own it.
- O -
Back from the working bench, right now all I can say is that some of the contracts WILL HAVE to change in the root container, and Stefano's 100% right, we cannot use the contracts outlined by Avalon4.
That said, I am sure that on an individual block level (forgetting about infra-block contracts) compatibility can be provided quite easily by re-wrapping some of the interfaces, providing some extensions, and doing some sh***y glue-work.
"Old" blocks can (IMVHO) work just fine in the new container, "New" blocks will work a bazillion times better! :-P
Pier
