Re: [Asterisk-java-devel] 2.0 release

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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... 
> <mailto: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...
>     <mailto:eng...@el...>
>     Tel: +49-241-566266-72 <tel:%2B49-241-566266-72>
>     Fax: +49-241-566266-29 <tel:%2B49-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...
>     <mailto: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 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