| [e4-dev] e4 Symposium at EclipseSummitEurope - part 1 |
| As the Eclipse wiki is down I am sending some notes from the e4 symposium to this list. Boris, Tom and I acted as organizers for the symposium, we had a significant attendance of 30-50 (50 when the modeling guys showed up) people. Based on the position papers we structured the symposium in 4 blocks: - Evolution of RCP - Declarative UI - Architecture, Programming model - User Interaction, Styling Evolution of RCP Kai Tödter and Tonny Madsen presented their position papers, and we had a very intense discussion about evolution vs. revolution, deprecation and best practices. This is the wishlist for the evolution of RCP: - reduce complexity - deprecate api that is not a best practice anymore - reduce footprint (icu ...) - better UI customization (this has been a killer criteria in some projects - they had to choose a different technology) - make best practices more evident, especially when there are multiple ways of doing things -- monkey see / monkey do is broken, because the platform is (often/sometimes) not adopting the best practices themselves -- make the mail demo use agreed best practices - take better advantage of p2 (also provide decent tooling for it) - introduce authentication, authorization A very important topic was the migration path from RCP 3.x to e4. People with an investment in RCP need a migration path and want e4 to be predictable - backward compatibility is crucial - deprecation of api that will no longer be supported must happen as soon as possible -- can we have tooling that helps adopters to see which parts of their apps are at risk -- can we establish a "communication channel" for adopters / producers based on automated tooling (e.g. "this change will bresk 348 adopters") For e4 to be a viable platform we should needs from adopters that do not come from the tooling area better into account - adopters should provide examples of what they wish to do (how can they provide examples if the stuff they want is not yet working?) - the team should use only best practices in the new platform - we should have many code samples, we should strive to involve the community for getting there (e.g. hackathons) A summary for the other blocks will follow, hopefully the wiki will be working again soon. Jochen ### Jochen Krause EclipseSource Tel: +49 721 664 7330 Fax: +49 721 664 73329 Innoopract Informationssysteme GmbHStephanienstrasse 20, 76133 Karlsruhe GermanyGeneral Manager: Jochen Krause Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883http://eclipsesource.com |