asterisk-java-devel Mailing List for Asterisk-Java Library (Page 3)
Brought to you by:
srt
Menu
▾
▴
asterisk-java-devel — Asterisk-Java Developer List
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
(8) |
Jul
(3) |
Aug
(6) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(8) |
Feb
(6) |
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
(17) |
Aug
(21) |
Sep
(2) |
Oct
(7) |
Nov
(8) |
Dec
(12) |
| 2007 |
Jan
(10) |
Feb
(19) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(5) |
Oct
(6) |
Nov
(1) |
Dec
(5) |
| 2008 |
Jan
(12) |
Feb
(15) |
Mar
(18) |
Apr
(34) |
May
(3) |
Jun
(34) |
Jul
(5) |
Aug
(1) |
Sep
(8) |
Oct
|
Nov
(2) |
Dec
(2) |
| 2009 |
Jan
(8) |
Feb
(2) |
Mar
(35) |
Apr
(16) |
May
(11) |
Jun
(2) |
Jul
(6) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(4) |
Dec
|
| 2010 |
Jan
(43) |
Feb
(15) |
Mar
(1) |
Apr
(7) |
May
(3) |
Jun
(7) |
Jul
(1) |
Aug
(3) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(2) |
Mar
(9) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
| 2012 |
Jan
(9) |
Feb
(2) |
Mar
(4) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(10) |
Nov
(10) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(10) |
Dec
|
| 2014 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(2) |
Mar
(7) |
Apr
(39) |
May
(18) |
Jun
(6) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
(9) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brett S. <bs...@no...> - 2015-04-29 03:59:17
|
Martin, to be honest I've not had much involvement in managing CI tools, so I'm happy to be guided by your sage advice :) I've asked Stefan to give us an account for CI on github. Will let you know when it is in hand. And thanks for putting your hand up :D Brett On 26/04/15 09:27, Martin Duncan wrote: > Brett, > > In terms of setting up CI, do you have a preference? Travis and Drone > are free, but require a project account to access the github repo. > > Regards, > Martin > > On Wed, Apr 22, 2015 at 12:13 AM Brett Sutton <bs...@no... > <mailto:bs...@no...>> wrote: > > > Wayne, > firstly appreciate the the offer. We can't get this project off the > ground without these types of offers, so thank you very much. > > <subliminal message to lurkers:>get off hairy arse and > contribute</subliminal message to lurkers> > > So what I'm hoping to create is a tutorial type set of examples with > growing complexity. > > Ideally the examples would be junit tests that would be placed in a > special examples directory of the test subdir. > In this way our examples would be unit tested as part of any CI we > setup. > > <need someone to set up CI - that could be YOU dear lurker> > > So essentially wiki documentation with worked examples, backed by > downloadable junit tests. > > So obvious examples are; dial, hangup, transfer, meetme, subscribe to > events etc. > > I would also like the java doc online and linked to the wiki. > > If anyone has better suggestions on how we should go about this, > please > chip in. > > Don't be shy I only eat children, not developers (I find > developers too > salty). > > Brett > > > On 21/04/15 21:39, Wayne Merricks wrote: > > Hi, > > > > I have a bunch of code on the live API that I can throw together in > > some sort of tutorial. The main Asterisk class I have is here: > > > > > https://github.com/waynemerricks/asteriskphone/blob/wip-work/src/com/thevoiceasia/phonebox/asterisk/AsteriskManager.java > > > > > > As a whole, the program is about 12,000 lines but the bit that hits > > Asterisk is approx 1,000 and at least half of that is internal > > tracking and XMPP message processing so not directly Asterisk > related. > > > > What sort of stuff are you looking for? > > > > Wayne Merricks > > The Voice Asia > > > > On 17/04/15 02:29, Brett Sutton wrote: > >> I'm looking for someone to volunteer to improve the online > documentation > >> and examples on the github wiki. > >> > >> I'm thinking that we should have a number of examples and links > to the > >> java doc online. > >> > >> A strong set of examples for common operations would help potential > >> users come up to speed quickly.. > >> > >> I've cc'd this to the user list as hoping that one of the > asterisk java > >> users might put up their hand. > >> > >> Yes I mean you! > >> > >> Don't just sit their and lurk :) > >> > >> Brett > >> > >> > ------------------------------------------------------------------------------ > >> > >> 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-users mailing list > >> Ast...@li... > <mailto:Ast...@li...> > >> https://lists.sourceforge.net/lists/listinfo/asterisk-java-users > > > > > -- > S. Brett Sutton > > Ph: 1300 NOOJEE (1300 666 533) > Noojee Telephony Solutions - On Demand Contact Centres Solutions > www.noojee.com.au <http://www.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... > <mailto:Ast...@li...> > https://lists.sourceforge.net/lists/listinfo/asterisk-java-devel > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > 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 |
|
From: Brett S. <bs...@no...> - 2015-04-29 03:53:51
|
Zoumana, appologies for the late reply, I've been bogged down this week. So yes make the release as soon as you are ready. The Monday timeline was really just a target to give anyone time that wanted to push any last minute updates. I need to get stefan to add you as a contributor so will send him a request today. And thank you for your support. Brett On 26/04/15 22:28, Zoumana TRAORE wrote: > Hello Brett, > > Are we still targeting tomorrow for a RC1 release? > I propose myself to do the tag and the github release, could you > please add me as contributor to the project and let me know? > > > Also let me know the time-frame you want the release to be published > (I'm in Paris time) > > > Zoumana > > > > *--- > * > > *Zoumana TRAORE* > > > 2015-04-17 12:05 GMT+02:00 Zoumana TRAORE <zou...@gm... > <mailto:zou...@gm...>>: > > Hi Brett, > > I will be glad to do so. > > Zoumana > > Le 17 avr. 2015 03:13, "Brett Sutton" <bs...@no... > <mailto:bs...@no...>> a écrit : > > So only a small no. of responses but the seems consistent. > > Basically lets get a 1.0 release candiated out the door asap. > > Our internal team have also agreed with the consensus view. > > So I'm proposing that we use the 1.0 branch that I created > about a week > ago and use that to create an 1.0 rc1. > > We will give you a short window to submit anything that you > think is > critical for the 1.0 release. > > If you have anything that you think should be critical to go > into that > release then please do a pull request by the 24th of April. > > We will only consider bug fixes and very very minor feature > changes. > Anything with a possible wide impact will be rejected. > > So unless there are any further objections we will look to > pushing out a > rc1 on Monday the 27th of April or there abouts. > > Do we have any one who would be happy to do the build and > submit the rc1 > code? > > > > Brett > > > ------------------------------------------------------------------------------ > 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 > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > 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 |
|
From: Enguerrand de R. <eng...@el...> - 2015-04-28 14:48:32
|
Can we talk about the branching strategy a bit more, I am not sure I am clear about the direction here. I just forked the repo on Github and would start incorporating changes I'd like to see in 1.1. I'd expect to branch each release branch off of develop and would hence be committing my changes to develop. However, Brett's mail below says we'll branch off 1.1. from 1.0, so now I am a bit confused. Can someone enlighten me as to which branch I should be working on to prepare something to be shared back via a pull request. Thanks Enguerrand ------------------------------------------------------------------------------------ Dipl.-Ing. Enguerrand de Rochefort Softwareentwickler mailto:eng...@el... Tel: +49-241-566266-72 Fax: +49-241-566266-29 -----Ursprüngliche Nachricht----- Von: Brett Sutton [mailto:bs...@no...] Gesendet: Freitag, 17. April 2015 02:48 An: ast...@li... Betreff: [Asterisk-java-devel] 1.1 release So given we have a decision on the 1.0 release lets nail down the details of 1.1. Give the low response I'm inclined to do the following. Create a 1.1 branch (need some help here should this be from the 1.0 branch or from master) The 1.1 branch will support the following 1.4 1.6 1.8 10 Subject to the assumption that we don't have to add any new major features to support these versions. 1.1. should be considered a bug fix release with perhaps a few wholes filled with minor features. An example of an acceptable feature might be support for a new action or event. An example of an un-acceptable feature would be anything that requires significant restructuring of the code. 1.1. should be a nice gentle release which aims to break nothing. Do we have someone(s) prepared to start the process of marshalling appropriate bug fixes and features into 1.1? Objections? Suggestions? Brett ------------------------------------------------------------------------------ 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 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. |
|
From: Zoumana T. <zou...@gm...> - 2015-04-26 12:29:00
|
Hello Brett, Are we still targeting tomorrow for a RC1 release? I propose myself to do the tag and the github release, could you please add me as contributor to the project and let me know? Also let me know the time-frame you want the release to be published (I'm in Paris time) Zoumana *---* *Zoumana TRAORE* 2015-04-17 12:05 GMT+02:00 Zoumana TRAORE <zou...@gm...>: > Hi Brett, > > I will be glad to do so. > > Zoumana > Le 17 avr. 2015 03:13, "Brett Sutton" <bs...@no...> a écrit : > >> So only a small no. of responses but the seems consistent. >> >> Basically lets get a 1.0 release candiated out the door asap. >> >> Our internal team have also agreed with the consensus view. >> >> So I'm proposing that we use the 1.0 branch that I created about a week >> ago and use that to create an 1.0 rc1. >> >> We will give you a short window to submit anything that you think is >> critical for the 1.0 release. >> >> If you have anything that you think should be critical to go into that >> release then please do a pull request by the 24th of April. >> >> We will only consider bug fixes and very very minor feature changes. >> Anything with a possible wide impact will be rejected. >> >> So unless there are any further objections we will look to pushing out a >> rc1 on Monday the 27th of April or there abouts. >> >> Do we have any one who would be happy to do the build and submit the rc1 >> code? >> >> >> >> Brett >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> > |
|
From: Martin D. <md...@du...> - 2015-04-25 23:28:04
|
Brett, In terms of setting up CI, do you have a preference? Travis and Drone are free, but require a project account to access the github repo. Regards, Martin On Wed, Apr 22, 2015 at 12:13 AM Brett Sutton <bs...@no...> wrote: > > Wayne, > firstly appreciate the the offer. We can't get this project off the > ground without these types of offers, so thank you very much. > > <subliminal message to lurkers:>get off hairy arse and > contribute</subliminal message to lurkers> > > So what I'm hoping to create is a tutorial type set of examples with > growing complexity. > > Ideally the examples would be junit tests that would be placed in a > special examples directory of the test subdir. > In this way our examples would be unit tested as part of any CI we setup. > > <need someone to set up CI - that could be YOU dear lurker> > > So essentially wiki documentation with worked examples, backed by > downloadable junit tests. > > So obvious examples are; dial, hangup, transfer, meetme, subscribe to > events etc. > > I would also like the java doc online and linked to the wiki. > > If anyone has better suggestions on how we should go about this, please > chip in. > > Don't be shy I only eat children, not developers (I find developers too > salty). > > Brett > > > On 21/04/15 21:39, Wayne Merricks wrote: > > Hi, > > > > I have a bunch of code on the live API that I can throw together in > > some sort of tutorial. The main Asterisk class I have is here: > > > > > https://github.com/waynemerricks/asteriskphone/blob/wip-work/src/com/thevoiceasia/phonebox/asterisk/AsteriskManager.java > > > > > > As a whole, the program is about 12,000 lines but the bit that hits > > Asterisk is approx 1,000 and at least half of that is internal > > tracking and XMPP message processing so not directly Asterisk related. > > > > What sort of stuff are you looking for? > > > > Wayne Merricks > > The Voice Asia > > > > On 17/04/15 02:29, Brett Sutton wrote: > >> I'm looking for someone to volunteer to improve the online documentation > >> and examples on the github wiki. > >> > >> I'm thinking that we should have a number of examples and links to the > >> java doc online. > >> > >> A strong set of examples for common operations would help potential > >> users come up to speed quickly.. > >> > >> I've cc'd this to the user list as hoping that one of the asterisk java > >> users might put up their hand. > >> > >> Yes I mean you! > >> > >> Don't just sit their and lurk :) > >> > >> Brett > >> > >> > ------------------------------------------------------------------------------ > >> > >> 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-users mailing list > >> Ast...@li... > >> https://lists.sourceforge.net/lists/listinfo/asterisk-java-users > > > > > -- > S. Brett Sutton > > Ph: 1300 NOOJEE (1300 666 533) > Noojee Telephony Solutions - On Demand Contact Centres Solutions > www.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 > > |
|
From: Brett S. <bs...@no...> - 2015-04-22 09:16:29
|
Wayne, firstly appreciate the the offer. We can't get this project off the ground without these types of offers, so thank you very much. <subliminal message to lurkers:>get off hairy arse and contribute</subliminal message to lurkers> So what I'm hoping to create is a tutorial type set of examples with growing complexity. Ideally the examples would be junit tests that would be placed in a special examples directory of the test subdir. In this way our examples would be unit tested as part of any CI we setup. <need someone to set up CI - that could be YOU dear lurker> So essentially wiki documentation with worked examples, backed by downloadable junit tests. So obvious examples are; dial, hangup, transfer, meetme, subscribe to events etc. I would also like the java doc online and linked to the wiki. If anyone has better suggestions on how we should go about this, please chip in. Don't be shy I only eat children, not developers (I find developers too salty). Brett On 21/04/15 21:39, Wayne Merricks wrote: > Hi, > > I have a bunch of code on the live API that I can throw together in > some sort of tutorial. The main Asterisk class I have is here: > > https://github.com/waynemerricks/asteriskphone/blob/wip-work/src/com/thevoiceasia/phonebox/asterisk/AsteriskManager.java > > > As a whole, the program is about 12,000 lines but the bit that hits > Asterisk is approx 1,000 and at least half of that is internal > tracking and XMPP message processing so not directly Asterisk related. > > What sort of stuff are you looking for? > > Wayne Merricks > The Voice Asia > > On 17/04/15 02:29, Brett Sutton wrote: >> I'm looking for someone to volunteer to improve the online documentation >> and examples on the github wiki. >> >> I'm thinking that we should have a number of examples and links to the >> java doc online. >> >> A strong set of examples for common operations would help potential >> users come up to speed quickly.. >> >> I've cc'd this to the user list as hoping that one of the asterisk java >> users might put up their hand. >> >> Yes I mean you! >> >> Don't just sit their and lurk :) >> >> Brett >> >> ------------------------------------------------------------------------------ >> >> 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-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/asterisk-java-users > -- S. Brett Sutton Ph: 1300 NOOJEE (1300 666 533) Noojee Telephony Solutions - On Demand Contact Centres Solutions www.noojee.com.au |
|
From: Brett S. <bs...@no...> - 2015-04-20 09:45:55
|
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 |
|
From: Enguerrand de R. <eng...@el...> - 2015-04-20 07:38:50
|
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.
|
|
From: Zoumana T. <zou...@gm...> - 2015-04-19 17:55:04
|
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 > > |
|
From: Brett S. <bs...@no...> - 2015-04-19 00:15:27
|
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
|
|
From: Sebastian <sc...@gm...> - 2015-04-17 14:15:52
|
I will try to get to them, maybe we can make something to integrate that library in a transparent manner. > On Apr 16, 2015, at 22:18, Brett Sutton <bs...@no...> wrote: > > Sebastian, > would you be will to start a conversation with ari4java guys and see if they are interested in a collaborative effort? > > It would seem silly for us to build ari lib if it already exists. Of course one argument is that it may make more sense for there to be two separate libraries but I haven't got my head around ARI to make a reasonable comment. > > Of course either way it would be sensible for the two groups to ensure interoperability so we don't tread on each others toes if a single application needs both libraries. > > Brett > > On 15/04/15 11:51, Sebastian wrote: >> This is how I would do based on your thoughts: >> >> >> release 1.0 as it is (is been long time there waiting) >> >> I’ve merged some forks to mine to start testing at least the ones that are more active towards Ast 13 but my plan is start testing for real >> about end of May, I was planing to start based on that but could change if we contact other developers with forks and merge all on the base project. >> >> >> Maybe we can make like 1.1 branch with pulls from others is there are any real fixes that are for all. >> >> if not I would move to a 2.0 version moving towards Ast 13 and ARI, >> >> ARI is supposed to be more performant than AMI and have a easier API based on REST, is suppose to be able to do more than AMI (the example they are always giving is that you could build your queue system or voicemail system using ARI and in this way make it more light weight), anyhow I still not that convinced on what can you really do that cannot do with AGI but they are going that way. >> >> We can also talk with someone from projects like https://github.com/l3nz/ari4java <https://github.com/l3nz/ari4java> to check if we can merge all in one project. (we already have AMI and AGI). >> >> I’ve also contribute some time ago on the asterisk-java-iax but I finally desisted and i’ve just used for some click to call apps (due to be easier to go through firewalls than sip) anyway that project is defunct from my point of view due to the incapacity of find developers to move it forward. >> >> About versions supported of asterisk I think that is possible to continue adding support to new releases adding the properties that are missing and letting the oldones too so the objects can have all of them, maybe add an identifier of the version in the object so you now how to proceed. >> >> I don’t know which versions are you using but I’ve been a long time in 10 and the plan is moving to 13 this year. >> >> let me know >> >> best regards >> >> >> >> >> >>> On Apr 14, 2015, at 22:22, Brett Sutton <bs...@no... <mailto:bs...@no...>> wrote: >>> >>> >>> So one of the Asterisk Java dev's sebastian has suggested ARI support in 2.0 >>> >>> So I've never used ARI nor have I read much about it. >>> >>> So there are a number of questions that come to mind. >>> >>> Does ARI give asterisk java any benefits or is it just another means of >>> communicating with asterisk. >>> >>> What is digiums intention with AMI vs ARI? >>> >>> Is ARI designed to replace AMI or will they always exists side by side. >>> >>> Are there any performance losses/gains with ARI compared with AMI. >>> >>> Can ARI do stuff that AMI can't. >>> >>> Other thoughts? >>> >>> >>> brett >>> >>> >>> ------------------------------------------------------------------------------ >>> 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- <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 <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 <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 <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 <http://www.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 |
|
From: Zoumana T. <zou...@gm...> - 2015-04-17 10:05:34
|
Hi Brett, I will be glad to do so. Zoumana Le 17 avr. 2015 03:13, "Brett Sutton" <bs...@no...> a écrit : > So only a small no. of responses but the seems consistent. > > Basically lets get a 1.0 release candiated out the door asap. > > Our internal team have also agreed with the consensus view. > > So I'm proposing that we use the 1.0 branch that I created about a week > ago and use that to create an 1.0 rc1. > > We will give you a short window to submit anything that you think is > critical for the 1.0 release. > > If you have anything that you think should be critical to go into that > release then please do a pull request by the 24th of April. > > We will only consider bug fixes and very very minor feature changes. > Anything with a possible wide impact will be rejected. > > So unless there are any further objections we will look to pushing out a > rc1 on Monday the 27th of April or there abouts. > > Do we have any one who would be happy to do the build and submit the rc1 > code? > > > > Brett > > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Zoumana T. <zou...@gm...> - 2015-04-17 10:03:34
|
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 > |
|
From: Enguerrand de R. <eng...@el...> - 2015-04-17 08:06:07
|
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. |
|
From: Brett S. <bs...@no...> - 2015-04-17 01:29:33
|
I'm looking for someone to volunteer to improve the online documentation and examples on the github wiki. I'm thinking that we should have a number of examples and links to the java doc online. A strong set of examples for common operations would help potential users come up to speed quickly.. I've cc'd this to the user list as hoping that one of the asterisk java users might put up their hand. Yes I mean you! Don't just sit their and lurk :) Brett |
|
From: Brett S. <bs...@no...> - 2015-04-17 01:18:31
|
Sebastian, would you be will to start a conversation with ari4java guys and see if they are interested in a collaborative effort? It would seem silly for us to build ari lib if it already exists. Of course one argument is that it may make more sense for there to be two separate libraries but I haven't got my head around ARI to make a reasonable comment. Of course either way it would be sensible for the two groups to ensure interoperability so we don't tread on each others toes if a single application needs both libraries. Brett On 15/04/15 11:51, Sebastian wrote: > This is how I would do based on your thoughts: > > > release 1.0 as it is (is been long time there waiting) > > I’ve merged some forks to mine to start testing at least the ones that > are more active towards Ast 13 but my plan is start testing for real > about end of May, I was planing to start based on that but could > change if we contact other developers with forks and merge all on the > base project. > > > Maybe we can make like 1.1 branch with pulls from others is there are > any real fixes that are for all. > > if not I would move to a 2.0 version moving towards Ast 13 and ARI, > > ARI is supposed to be more performant than AMI and have a easier API > based on REST, is suppose to be able to do more than AMI (the example > they are always giving is that you could build your queue system or > voicemail system using ARI and in this way make it more light weight), > anyhow I still not that convinced on what can you really do that > cannot do with AGI but they are going that way. > > We can also talk with someone from projects like > https://github.com/l3nz/ari4java to check if we can merge all in one > project. (we already have AMI and AGI). > > I’ve also contribute some time ago on the asterisk-java-iax but I > finally desisted and i’ve just used for some click to call apps (due > to be easier to go through firewalls than sip) anyway that project is > defunct from my point of view due to the incapacity of find developers > to move it forward. > > About versions supported of asterisk I think that is possible to > continue adding support to new releases adding the properties that are > missing and letting the oldones too so the objects can have all of > them, maybe add an identifier of the version in the object so you now > how to proceed. > > I don’t know which versions are you using but I’ve been a long time in > 10 and the plan is moving to 13 this year. > > let me know > > best regards > > > > > >> On Apr 14, 2015, at 22:22, Brett Sutton <bs...@no... >> <mailto:bs...@no...>> wrote: >> >> >> So one of the Asterisk Java dev's sebastian has suggested ARI support >> in 2.0 >> >> So I've never used ARI nor have I read much about it. >> >> So there are a number of questions that come to mind. >> >> Does ARI give asterisk java any benefits or is it just another means of >> communicating with asterisk. >> >> What is digiums intention with AMI vs ARI? >> >> Is ARI designed to replace AMI or will they always exists side by side. >> >> Are there any performance losses/gains with ARI compared with AMI. >> >> Can ARI do stuff that AMI can't. >> >> Other thoughts? >> >> >> brett >> >> >> ------------------------------------------------------------------------------ >> 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 |
|
From: Brett S. <bs...@no...> - 2015-04-17 01:12:30
|
So only a small no. of responses but the seems consistent. Basically lets get a 1.0 release candiated out the door asap. Our internal team have also agreed with the consensus view. So I'm proposing that we use the 1.0 branch that I created about a week ago and use that to create an 1.0 rc1. We will give you a short window to submit anything that you think is critical for the 1.0 release. If you have anything that you think should be critical to go into that release then please do a pull request by the 24th of April. We will only consider bug fixes and very very minor feature changes. Anything with a possible wide impact will be rejected. So unless there are any further objections we will look to pushing out a rc1 on Monday the 27th of April or there abouts. Do we have any one who would be happy to do the build and submit the rc1 code? Brett |
|
From: Brett S. <bs...@no...> - 2015-04-17 01:02:50
|
So lets talk about the 2.0 release.
The objective of 2.0 will be to support Asterisk Java 11, 12 and 13 in
addition to the already supported versions.
At this point I don't see 2.0 supporting ARI, I'm thinking that should
be a 3.0 target.
I do however want to open up the discussion about improving the 2.0
interface.
One concern I have with what I'm about to propose is that it has the
potential to break binary compatibility.
But lets talk anyway.
One of the frustrations I have with asterisk java is that Channels and
Endpoints are all treated as string.
There are a number of places in the code base that claim something is a
channel when if fact it isn't.
To solve this problem in our code base we have a event/action
translation layer which converts Channels and End point strings to
actual classes of the same name.
Once the conversion is down we have found that it significantly reduces
the amount of code to handle channels and end points as well as reducing
the bugs around handling nulls and empty strings.
The second and related issues is that the method of using strings to
store channels is that it causes problems when rename events occur. Its
my understanding that in 13 and the new sip libraries that rename events
go away. That however doesn't help anyone using an earlier version of
asterisk java and it means that you have to have two different code
bases to handle the different versions of asterisk.
In our code base along with the above classes for Channels and Endpoints
we also transparently handle rename events. The Channel object is
actually a proxy for the actually channel so we can rename the Channel
under the hood with the code needing to be aware of the change.
So Noojee is willing to donate the code we have to does the above. The
question is whether it will cause a major breakage of code (uncertain
although a decent toString method on the classes may make this
transparent) and whether we should be considering what amounts to a
fairly major change to the code base.
Here are the interfaces we use:
package au.com.noojeeit.pbx;
import au.com.noojeeit.pbx.asterisk.InvalidChannelName;
/**
* Provides an abstraction for an channel object which is independent
of the
* underlying PBX.
*
* @author bsutton
*
*/
public interface iChannel
{
/**
* Compares if two channels are the same logical channel on the pbx.
*
* This comparison uses the full unique name of the channel not
just the
* abbreviated peer name. e.g. SIP/100-00000100
*
* @param rhs
* @return
*/
boolean isSame(iChannel rhs);
boolean isSame(String channelName, String uniqueID);
/*
* This comparision uses just the peer name. e.g. SIP/100
*/
boolean sameEndPoint(iChannel rhs);
/*
* This comparision uses just the peer name. e.g. SIP/100
*/
boolean sameEndPoint(iEndPoint endPoint);
/**
* Compares if this channel is the same as the named channel.
*
* @param channelName
* @return
*/
boolean sameExtenededChannelName(String channelName);
/**
* This method does not actually change the state of the channel,
rather it
* is intended to be used to record the fact that the state has
changed.
*
* @see public iPBX.iParkCallActivity park(iChannel channel, Direction
* direction, boolean parkState) for a method which actually
parks the
* channel.
*/
void setParked(boolean parked);
/**
* This method does not actually change the state of the channel,
rather it
* is intended to be used to record the fact that the state has
changed.
*
* @see public iPBX.iMuteCallActivity mute(iChannel channel, Direction
* direction, boolean muteState) for a method which actually
mutes the
* channel.
*/
void setMute(boolean muteState);
/**
* Each channel is assigned a unique PBX independent id to help
track the
* channels when logging.
*
* @return
*/
long getChannelId();
/**
* Returns true if the channel is alive. A channel is considered to
be alive
* from the moment it is created until we get a notification that
it has
* been hungup.
*
* @return
*/
boolean isLive();
/**
* Adds a listener to the channel. The channel will send a hungup
* notification to the listener when it hungup. A channel must be
able to
* support multiple listeners.
*
* @param call
*/
void addListener(iChannelHangupListener listener);
void removeListener(iChannelHangupListener listener);
/**
* Returns true if the given endpont is currently connected to this
channel.
*
* @param extension
* @return
*/
boolean isConnectedTo(iEndPoint endPoint);
/**
* returns a fully qualifed channel name which includes the tech. e.g.
* SIP/100-00000342
*
* @return
*/
String getChannelName();
iEndPoint getEndPoint();
/**
* Checks if this channel is currently mute. A channel is mute if
the party
* connected to this channel cannot hear any audio.
*
* @return
*/
boolean isMute();
/**
* In Asterisk speak, this method returns true if it is a LOCAL/
channel Not
* quite certain how this will map to other pbx's
*
* @return
*/
boolean isLocal();
/**
*
* @return true if the channel is currently parked.
*/
boolean isParked();
/**
* Returns true if the channel has been marked as in a zombie state.
*
* @return
*/
boolean isZombie();
/**
*
* @return true if the channel was originated from the console
* (Console/DSP).
*/
boolean isConsole();
/**
* Returns the current callerid for this channel.
*
* Note: on some systems this involves a round trip to the pbx.
*
* @return
*/
iCallerID getCallerID();
/**
* Called to rename a channel
*
* @param newname
* the new name of the channel
* @throws InvalidChannelName
*/
void rename(String newName) throws InvalidChannelName;
/**
* Returns a PBX specific version of the Channel name.
*
* @return
*/
String getExtendedChannelName();
void notifyHangupListeners();
boolean canDetectHangup();
boolean isQuiescent();
boolean hasCallerID();
}
package au.com.noojeeit.pbx;
import au.com.noojeeit.pbx.asterisk.core.Tech;
/**
* Provides an abstract interface for entities which can be dialed.
*
* This encompasses entities such as: Phone extensions SIPPeers Asterisk
* extensions External phone numbers
*
* @author bsutton
*
*/
public interface iEndPoint extends Comparable<iEndPoint>
{
public boolean isSame(iEndPoint rhs);
public boolean isLocal();
public boolean isSIP();
/**
* Returns the fully qualified name of the EndPoint including the
tech. e.g.
* SIP/100
*
* @return
*/
public String getFullyQualifiedName();
/**
* Returns the simple name of the EndPoint sans the tech. e.g.
SIP/100 would
* be returned as 100.
*
* @return
*/
public String getSimpleName();
/**
* Returns the simple name of a SIP EndPoint sans the tech. e.g.
SIP/100 would
* be returned as 100.
* If the endpoint is not actually a SIP end point then this method
* returns the full end point name.
*
*
* @return
*/
public String getSIPSimpleName();
/**
* Returns true if the tech is not know for this end point.
*
* @return
*/
public boolean isUnknown();
/**
* Returns the Tech that is used to reach this endpoint.
*
* @return
*/
public Tech getTech();
public boolean isEmpty();
/**
* Sets the tech on the end point to the specified tech.
*
* @param sip
*/
// public void setTech(Tech tech);
}
|
|
From: Brett S. <bs...@no...> - 2015-04-17 00:48:22
|
So given we have a decision on the 1.0 release lets nail down the details of 1.1. Give the low response I'm inclined to do the following. Create a 1.1 branch (need some help here should this be from the 1.0 branch or from master) The 1.1 branch will support the following 1.4 1.6 1.8 10 Subject to the assumption that we don't have to add any new major features to support these versions. 1.1. should be considered a bug fix release with perhaps a few wholes filled with minor features. An example of an acceptable feature might be support for a new action or event. An example of an un-acceptable feature would be anything that requires significant restructuring of the code. 1.1. should be a nice gentle release which aims to break nothing. Do we have someone(s) prepared to start the process of marshalling appropriate bug fixes and features into 1.1? Objections? Suggestions? Brett |
|
From: Martin D. <md...@du...> - 2015-04-17 00:15:09
|
I have done a little bit of exploratory work with ARI4Java. It is an excellent library, but several things stood out. * ARI is tough in a multi-threaded environment * Just like AMI, it is event driven and gives you a lot of control. The downside, is that you have to orchestrate a large number of events. This can be overcome, but is a consideration especially at high-volume. All of the examples on the Digium github site ( https://github.com/asterisk/ari-examples) use Python and Javascript libraries that handle much of the plumbing of catching different events. * ARI uses multiple TCP connections * Part of the challenge is not only to manage which event goes with which event flow across threads, but also across an arbitrary number of connections. ARI4Java uses Netty which has an interesting solution for this, however, grizzly may also fit. There my be other libraries as well that could do this sort of thing, but I have looked at those two in depth. * ARI is still changing quickly * The ARI API is already at version 1.7. So this is a moving target. They provide Swagger bindings for there services which is helpful. However, getting Swagger-codegen up and running is trickier than you would think from the Swagger website. * ARI is an Application API * ARI seems designed to allow you to create your own dialplan applications. Most of their examples at conferences have been around creating your own voice-mail application, or call queue application. This is a pretty powerful concept. In an ideal world, opening up this kind of API should lead to the development of "shareable" modules that could be plugged into asterisk without the need to learn C or the headaches of ABI compatibility. To make a long story short. It is still easier to do most things in AGI. It is still easier to get asterisk events from AMI. But if you want something small, composible and low-level, ARI might be a better choice. Regards, Martin |
|
From: Martin D. <md...@du...> - 2015-04-15 04:28:52
|
Here are my votes: Issue 1 Put out 1.0 with NO FIXES. Once people see some activity with the library, they will be more likely to make pull/push requests. Also, we could use feedback from the 1.0 release to help prioritize additional work for 1.1 Issue 2 I think we should ask the developers first, but if they don't respond, then I think you are correct and there is no alternative, but to do it ourselves. Issue 3 We should target the features in 1.8 in the 1.X version. This seems like a popular version. It is important to specify that I want to support the feature set. I am using the current version of asterisk-java against version 13.3, but only using basic AMI and AGI features and it works well. Claiming that we support 12 or 13 implies that there is support for ARI, which would be it's own development effort. Issue 4 We should target the features in 13+ in the 2.X version. At some point, ARI will have to either be in or out. A more forward looking effort after stabilizing the code base sounds like the time to do that. |
|
From: Sebastian <sc...@gm...> - 2015-04-15 01:53:22
|
This is how I would do based on your thoughts: release 1.0 as it is (is been long time there waiting) I’ve merged some forks to mine to start testing at least the ones that are more active towards Ast 13 but my plan is start testing for real about end of May, I was planing to start based on that but could change if we contact other developers with forks and merge all on the base project. Maybe we can make like 1.1 branch with pulls from others is there are any real fixes that are for all. if not I would move to a 2.0 version moving towards Ast 13 and ARI, ARI is supposed to be more performant than AMI and have a easier API based on REST, is suppose to be able to do more than AMI (the example they are always giving is that you could build your queue system or voicemail system using ARI and in this way make it more light weight), anyhow I still not that convinced on what can you really do that cannot do with AGI but they are going that way. We can also talk with someone from projects like https://github.com/l3nz/ari4java <https://github.com/l3nz/ari4java> to check if we can merge all in one project. (we already have AMI and AGI). I’ve also contribute some time ago on the asterisk-java-iax but I finally desisted and i’ve just used for some click to call apps (due to be easier to go through firewalls than sip) anyway that project is defunct from my point of view due to the incapacity of find developers to move it forward. About versions supported of asterisk I think that is possible to continue adding support to new releases adding the properties that are missing and letting the oldones too so the objects can have all of them, maybe add an identifier of the version in the object so you now how to proceed. I don’t know which versions are you using but I’ve been a long time in 10 and the plan is moving to 13 this year. let me know best regards > On Apr 14, 2015, at 22:22, Brett Sutton <bs...@no...> wrote: > > > So one of the Asterisk Java dev's sebastian has suggested ARI support in 2.0 > > So I've never used ARI nor have I read much about it. > > So there are a number of questions that come to mind. > > Does ARI give asterisk java any benefits or is it just another means of > communicating with asterisk. > > What is digiums intention with AMI vs ARI? > > Is ARI designed to replace AMI or will they always exists side by side. > > Are there any performance losses/gains with ARI compared with AMI. > > Can ARI do stuff that AMI can't. > > Other thoughts? > > > brett > > > ------------------------------------------------------------------------------ > 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 |
|
From: Brett S. <bs...@no...> - 2015-04-15 01:22:59
|
So one of the Asterisk Java dev's sebastian has suggested ARI support in 2.0 So I've never used ARI nor have I read much about it. So there are a number of questions that come to mind. Does ARI give asterisk java any benefits or is it just another means of communicating with asterisk. What is digiums intention with AMI vs ARI? Is ARI designed to replace AMI or will they always exists side by side. Are there any performance losses/gains with ARI compared with AMI. Can ARI do stuff that AMI can't. Other thoughts? brett |
|
From: Brett S. <bs...@no...> - 2015-04-15 01:06:19
|
So I'm a little uncertain of the best path, my thoughts are along the lines of: There are a number of forks (lots) that have bug fixes which would be useful to get into the 1.0 release. I also get the impression that a number of the users of these forks have fixes that they deem critical for their environment. The question then is how many (if any) of these we should wrap up into the 1.0 release. One possible path is lets just do the 1.0 release as the code stands, so that downloaders have some level of confidence when the get the 1.0 release and lets us get it out the door quickly. We could then look at a 1.1 release that takes the bug fixes from these many forks. With either scenario we need to work out how we get the fixes from those forks in to the 1.x release. We can try contacting some of the developers (I've tried with some but not all have email addresses attached) and request them to send us push requests against the 1.x branch or failing that we could start picking off bug fixes from those forks and generate the pull requests ourselves. We also need to determine what versions of asterisk we will support for 1.0 vs 2.0 I've included asterisk-users on this thread as while these are development issues I think we need to here what our users need. So opinions on the best path? So vote: Issue 1: Create release 1.0 using existing code with NO fixes, then 1.1 with fixes. Create release 1.0 with fixes. Issue 2: Request developers to make push requests. Marshall the forks and do push requests ourselves. Issue 2 may be a noop in the sense that if fork developers don't respond then we will have to do it ourselves. Issue 3: Choose which versions of asterisk must be supported in 1.0. 1.4 1.6 1.8 10 11 12 13 Choose which versions of asterisk must be supported in 2.0 1.4 1.6 1.8 10 11 12 13 14 Brett On 15/04/15 06:03, Martin Duncan wrote: > > Brett, > > It all sounds good. Let me know which has the highest priority and I > will start on that. > > Regards, > > Martin > > > > ------------------------------------------------------------------------------ > 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 |
|
From: Martin D. <md...@du...> - 2015-04-14 20:03:44
|
Brett, It all sounds good. Let me know which has the highest priority and I will start on that. Regards, Martin |
3 messages has been excluded from this view by a project administrator.
