Re: [Asterisk-java-devel] 2.0 release

[Brett S. <bs...@no...>]

yes that was exactly my thought process.


I've seen other projects die because a lack of backward compatibility 
between releases so I'm keen to avoid that death.




On 20/04/15 17:38, Enguerrand de Rochefort wrote:
>
> Hi Brett
>
> to me this sounds very good. Would it make sense to make the 
> transition a bit easier by adding a (possibly even deprecated) method 
> to the iChannel interface that returns the String that would 
> previously have been the channel representation?
>
> So when I plug in the new asterisk-java lib I will get a ton of 
> compile errors, but all I’ll have to do in a first step to fix each of 
> them is replacing “getChannel()” by 
> “getChannel().getLegacyStringRepresentation()” or something similar?
>
> Cheers
>
> Enguerrand
>
> ------------------------------------------------------------------------------------
>
> Dipl.-Ing. Enguerrand de Rochefort
>
> Softwareentwickler
>
> mailto:eng...@el...
>
> Tel: +49-241-566266-72
>
> Fax: +49-241-566266-29
>
> *Von:*Brett Sutton [mailto:bs...@no...]
> *Gesendet:* Sonntag, 19. April 2015 02:15
> *An:* ast...@li...
> *Betreff:* Re: [Asterisk-java-devel] 2.0 release
>
> So clearly I was very clear in my original post, so let me take a 
> minute to clear things up so we have a clear view of where we are 
> going.  Is that clear :)
>
> So the intent for 2.0 is that it will support version of Asterisk from 
> 1.4 to 13.
>
> There will be no need to run different versions of Asterisk java to 
> support different version of asterisk.
>
> >From the 3.0 version its probably worth think about culling some of 
> the older versions, but this will depend on how hard it is to support 
> the older versions.
>
> In the end the version that we support really comes down to what test 
> environments we can managed to set up.
>
> As Enguerrand has suggested and as Stefan has down previously we can 
> normally support both versions by mapping older legacy events actions 
> to the new action/events.  We will obviously have to look into this on 
> a case by case basis but I'm moderately confident that this can be 
> managed. The only issue will be where an older version of asterisk 
> doesn't support some of the attributes provided by the latest version.
>
> So hopefully that makes things a little clearer.
>
> Now my statements about breaking compatibility where not with respect 
> to the version of asterisk. What I was talking about was the 
> possibility of breaking the asterisk-java api compatibility in an 
> effort to make the events/actions easier to use. The main idea being 
> to replace channel and endpoint string in events and actions with 
> actual classes.
>
> As an example the current LogChannelEvent has the following fields:
>
>    private String channel;
>     private Boolean enabled;
>     private Integer reason;
>     private String reasonTxt;
>
>
> These fields would be modified to be:
>
>    private iChannel channel;
>     private Boolean enabled;
>     private Integer reason;
>     private String reasonTxt;
>
> Where iChannel is an interface to a Channel implementation that 
> provides a set of useful channel related operations.
>
> Our experience with doing the substitution is that interacting with 
> asterisk becomes much easier, the code is easier to read and we 
> eliminated a number of bugs at compile time.
>
> Have I made this clearer?
>
> What do people think about the idea of using classes for channels and 
> endpoints rather than strings?
>
> Brett
>
>
>
> ELARA Leitstellentechnik GmbH Member of Frequentis Group 
> Schloss-Rahe-Str. 19a 52072 Aachen Geschäftsführender Gesellschafter: 
> Dr.-Ing. Frank Herzog Geschäftsführer: Dipl.-Ing. Hans Werner Güntzel 
> Amtsgericht Aachen HRB 17856 St.-Nr.: 201/5956/4218 USt-IdNr.: DE 285 
> 827 521 
> --------------------------------------------------------------------------------------------- 
> Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte 
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese 
> E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den 
> Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie 
> die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail 
> may contain confidential and/or privileged information. If you are not 
> the intended recipient (or have received this e-mail in error) please 
> notify the sender immediately and destroy this e-mail. Any 
> unauthorized copying, disclosure or distribution of the material in 
> this e- mail is strictly forbidden.
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>
>
> _______________________________________________
> Asterisk-java-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-devel


-- 
S. Brett Sutton

Ph: 1300 NOOJEE (1300 666 533)
Noojee Telephony Solutions - On Demand Contact Centres Solutions
www.noojee.com.au