[Blink] New Blink Qt release 0.2.0 for Microsoft Windows

[Dan Pascu]

On 12 Nov 2010, at 16:23, François Delawarde wrote:

> On Fri, 2010-11-12 at 14:31 +0200, Dan Pascu wrote:
>> Anyone should be able to contribute a feature. Blink is an
>> open-source
>> project. 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.
>
> Nice idea, sounds hard but I can try to look into it. Can you give me
> hints to find some API documentation for me to read?

You may be interested in the python-sipsimple API (you can find  
documentation about it here):

http://sipsimpleclient.com/

You'll need to implement the REFER method in order to support call  
transfers. After that REFER needs to be used to implement the call  
transfer in blink and some way to initiate the call transfer needs to  
be designed for the UI.

There is no API documentation for blink as blink is an application not  
a library/API to be used by other software. So the only blink  
documentation has, is its code, which I'd say is pretty well organized  
and should be easy to dig into (the blink-qt code I mean).

> Also, if someone develops a feature, must he port it to Blink Cocoa if
> only interested in Blink QT?

No. It will be ported eventually, either by us if it is  
straightforward, or by someone who is interested by the same  
functionality to be available on OS X.

We do not impose restrictions on what a contributor should implement.  
That's up to them. We only decide if something will be included based  
on:

1. How useful a feature is for other people.
2. 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).
3. The code must follow the coding conventions already in place in  
blink, 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:

http://www.python.org/dev/peps/pep-0008/
http://www.python.org/dev/peps/pep-0007/

It would be good to discuss design with us early so we can find a good  
approach and avoid multiple costly iterations later. Also follow the  
coding style in order to avoid similar multiple iterations before the  
code is admitted.

--
Dan