Re: [Asterisk-java-devel] 2.0 release

[Zoumana T. <zou...@gm...>]

Hello Brett,

Clearly, this is now clearer :-)
About your code suggestion: based on your return of experience (clear code,
easy to read and refactor, avoiding bugs) i don't have nothing against,
quite opposite if it can make our life (dev) easier :-)e

Zoumana


Le 19 avr. 2015 02:16, "Brett Sutton" <bs...@no...> a écrit :

>  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
>
>
>
> On 17/04/15 20:03, Zoumana TRAORE wrote:
>
> Hello everyone,
>
> Same as Enguerrand, IMHO we shoud consider keeping the backwards
> compatibility not forcing projects to have different code bases and builds
> processes...
>
> Regards,
> Zoumana
> Le 17 avr. 2015 10:07, "Enguerrand de Rochefort" <
> eng...@el...> a écrit :
>
>> Hi Brett
>>
>> I can say that
>> "it means that you have to have two different code bases to handle the
>> different versions of asterisk."
>> would not work for us. For a smooth  roll-out of Asterisk 13 we need to
>> support Asterisk 13 and all currently supported versions in parallel.
>>
>> That said, if I am the only one who sees it that way it should not affect
>> your decision on how to proceed, because I have already brought the current
>> codebase to a level that works with Asterisk 13 and Asterisk 1.4 in
>> parallel, so for us the problem is addressed, albeit in a way that only
>> covers the features our application actually makes use of. Anyways, I am
>> thinking that others might be in the same situation.
>>
>> This goes back to my previous mail regarding backward compatibility,
>> which first went to asterisk-users by mistake and then was bounced by
>> asterisk-devel because it exceeded 40 kb (which is why I removed your mail
>> from this reply, so hopefully this one goes through). The key sentence was
>>
>> "I think we'd have to agree on a strategy for backwards compatibility.
>> E.g. some user events got some major restructuring in Asterisk 12.
>> Applications that expect the old structure of e.g. Dial-, Hold- and Park
>> Events may no longer work correctly if we just adjust to the new structure.
>> The problems I have encountered so far could be overcome by building
>> additional legacy Events from the new Events and sending them out as well,
>> but that obviously does not lead to cleaner code and may actually produce
>> unexpected side effects."
>>
>> Regards
>> Enguerrand
>>
>>
>> ------------------------------------------------------------------------------------
>> Dipl.-Ing. Enguerrand de Rochefort
>> Softwareentwickler
>> mailto:eng...@el...
>> Tel:  +49-241-566266-72
>> Fax: +49-241-566266-29
>>
>>
>> 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
>>
>
>
> ------------------------------------------------------------------------------
> 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 exerciseshttp://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 lis...@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 Solutionswww.noojee.com.au
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>