Re: [Asterisk-java-devel] 2.0 release

[Enguerrand de R. <eng...@el...>]

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.