--- On Fri, 4/2/10, Eric Varsanyi <[email protected]> wrote: > Another .02 from me: All the areas I've dug into in the > 'core' path except for sipxconfig are fairly clear and easy > to pick apart and hack on if you have some idea of how the > system is put together. High level docs showing how > everything fits together (what each daemon is responsible > for and how they communicate) would help a *great* deal for > these areas. Having working examples as you suggest is > wonderful (though in practice I've found its hard to keep > such things up to date as time goes by). > > SipxConfig requires understanding not just the underlying > language but how spring, hibernate, tapestry (old version), > GWT, and velocity work (as well as understanding the phone > hardware and its config language/etc) -- after all that > you're finally in a position to try to understand how > sipXconfig is put together with those parts and think about > changes. I really like its overall architecture and use of > fairly modern frameworks but IMO you'll never run into a non > developer or a developer who isn't already familiar with > most of various technologies involved who will be able to > get any traction for a 'quick project'.
For those developers you mentioned - it definitely worth spending time on these technologies - at the end you'll find out that it let you focus on business logic rather than reinventing J2EE wheels. And you can use the gained knowledge in other projects as well (I certainly did in several). Kudos again to the sipxconfig guys that choose and enforced proper usage of these technologies! > A top level architecture/HLD page on how the actual sipXconfig code is > put together (not trying hard to explain the technologies, > they are well documented elsewhere) would have saved lots of > casting about for me anyway. I think an 'how to develop a sipxconfig page' tutorial (highlighting the places where various technologies comes in scene) would be great. > > > I wish we could have an "openfire like" plugin > architecture for sipx > > so extensions can be easily developed and > deployed along with config > > pages for these extensions. > > It would be a *major* win to be able to write plugins and > deploy them w/o a rebuild (esp in the sipXconfig space). > Proposed features that are not immediately accepted into the > codebase can't really be tested/played with easily by > adventurous users since the build/deploy process is fairly > heavyweight. Nothing that cannot be done. Incidentally I spent some time on Tapestry5 and was very excited about the modularization it comes with (great tutorial here: http://blog.tapestry5.de/index.php/2010/01/19/tapestry-ioc-modularization-of-web-applications-without-osgi/) - though didn't find time yet for a proof of concept. Would be a challenge to migrate existing code but definitely a way for a pluggable sipxconfig. (dreaming on plugins as OSGi bundles, easy to manage at runtime without restarting config...) Regards, George _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
