SylkServer is an open-source project. Anyone should be able to contribute if they want a new feature implemented. The only requirement for the code to be accepted is to be well written and maintainable. If someone needs a feature that's important to them but it's not on our roadmap, they can contribute it.
The decision if something will be included in the official repository is based on:
- How useful a feature is for other people.
- The code that adds the feature must be well designed. The design should be clean, simple and self contained, avoiding complex dependencies on other parts of the code as much as possible. The code should be self documenting (well named classes, methods, variables that help understand what they intend to do without resorting to comments or external documentation).
- The code must follow the coding conventions already in place, regarding naming conventions, spacing, etc. We mainly use python's pep8 for our coding style in python and pep7 for the C code in case there is a python extension involved. They are available here:
It is wise to discuss the design first on the Mailinglists so that the best approach is found to avoid multiple costly iterations later. Also follow the coding style in order to avoid similar multiple iterations before the code is admitted.
Creating new applications
To create a new application you must write it in a way to comply with the ISylkApplication interface. The interface is described in sylk/applications folder. See the conference room application provided with the server for a complete working example. You will need to define at least a handler by overwriting one of the following functions and then add the application to the server registry:
The Protocols Layer is described in the Middelware API section of SIP SIMPLE client SDK.
How to submit a patch
First make sure you are using the latest version by doing a 'darcs pull'. Then record your changes using 'darcs record'. Follow the following guidelines for recording your changes:
- Keep a patch name under 80 characters, so that a darcs changes in a 80 char console is consistent and readable. If you need to write more than that, use --edit-long-comment or do not specify -m "patch name" and it will automatically ask for a patch name and a long comment. Keep the long comment inside the 80 char frame.
- When you add a long comment, you have the patch name on the first line. After that, leave an empty line and then add the long comment starting from the 1st column. If you need to add bulleted entries in the long comment, use a dash (-) not an asterisk (*), to avoid confusion with the asterisk darcs places before every patch name.
- Record separate patches for each distinct changes you make. Do not mix different changes in a single record.
- Use darcs replace to rename tokens if possible instead of using a search and replace in your editor. It correctly handles cases where someone else still kept using the old name (it will automatically rename this uses of the old name when he pull the darcs replace patch, which a simple token rename done by the editor and recorded as a standard diff will never do, requiring further patches to rename the old tokens that the other developer added in his code while you were doing the renaming).
Finally, send the patch describing your changes at::
darcs send --to email@example.com
If you are not sure what and where needs to be modified, ask the question first on the SIP Beyond Voip mailing list.