> > You should not need to be part of the priesthood to develop code for > sipx. It is not rocket science. > > sipx is a complex project and requires extensive domain knowledge; > however some examples and HOW to docs would help. > > > I'd like to throw in an examples project in the distribution. Some > ideas (please chime in if you have others): > > A simple user agent that gets visited in the signaling path ( all the > business about redirector plugins that I am finding out about ). > > A simple back to back user agent that stays in the signaling path > (and does nothing but forward signaling). > > A simple redirector plugin. > > A simple auth plugin. > > A simple gateway that proxies requests to the wide blue yonder. >
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'. 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 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. Thanks for opening up all this to discussion and being so willing to help on the lists. IMO a lot of what makes community and the willingness to contribute is the feeling if you get stuck someone will be there to help you out too. -Eric _______________________________________________ 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/
