Menu
▾
▴
gjtapi-developers — Developer's Mailing List for Generic JTAPI and JCC Project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(10) |
Apr
(2) |
May
(9) |
Jun
(4) |
Jul
(7) |
Aug
(8) |
Sep
(11) |
Oct
(16) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(1) |
Feb
(2) |
Mar
(4) |
Apr
(6) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
(1) |
| 2004 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(11) |
Apr
(5) |
May
(3) |
Jun
|
Jul
|
Aug
(5) |
Sep
(5) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2006 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
(3) |
Jun
(3) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(11) |
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(3) |
Dec
|
|
From: Johannes B. <B0...@gm...> - 2011-11-21 13:57:15
|
As I wrote on 1.10.2011 I converted the cvs repository to git. You can get a copy of it at http://dickeradmin.de/resources/gjtapi.git.zip . If there was no activity since that post you can just use that git repository and push it to sourceforge. Iso think you've got to enable git on sourceforge first and maybe you can set cvs to readonly then maybe? In case mething is not clear just ask. I'll gladly give support concerning the transmission. Thanks, JB > Betreff: Re: [Gjtapi-developers] Switch vcs? > Johannes, > > Sorry for not getting back to you. I was distracted with other non-GJtapi > things. > > I've only heard positive feedback about switching to Git. Unless anyone > has > any last-second protests, let's go ahead with it. What would the next > steps > be? > > Thanks, > > > Richard > > On Mon, Nov 21, 2011 at 4:36 AM, Johannes Boesl <B0...@gm...> wrote: > > > Hi there, > > > > any thoughts on the 'switch vcs' proposal? I didn't get any feedback on > my > > last post. At least a 'yes we can switch in the future as soon as we've > got > > some spare time' or 'no a switch won't happen' would be nice. > > > > With kind regards, > > JB > > > > > -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de |
|
From: Richard D. <rde...@de...> - 2011-11-21 12:35:57
|
Johannes, Sorry for not getting back to you. I was distracted with other non-GJtapi things. I've only heard positive feedback about switching to Git. Unless anyone has any last-second protests, let's go ahead with it. What would the next steps be? Thanks, Richard On Mon, Nov 21, 2011 at 4:36 AM, Johannes Boesl <B0...@gm...> wrote: > Hi there, > > any thoughts on the 'switch vcs' proposal? I didn't get any feedback on my > last post. At least a 'yes we can switch in the future as soon as we've got > some spare time' or 'no a switch won't happen' would be nice. > > With kind regards, > JB > -- > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! > Jetzt informieren: http://www.gmx.net/de/go/freephone > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Gjtapi-developers mailing list > Gjt...@li... > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers > |
|
From: Johannes B. <B0...@gm...> - 2011-11-21 09:36:18
|
Hi there, any thoughts on the 'switch vcs' proposal? I didn't get any feedback on my last post. At least a 'yes we can switch in the future as soon as we've got some spare time' or 'no a switch won't happen' would be nice. With kind regards, JB -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone |
|
From: Johannes B. <B0...@gm...> - 2011-10-01 00:06:29
|
Hi Richard, sorry for not answering earlier. I was on holidays. I just converted the cvs repository to git. The branches, labels and commit-messages are all retained. You can browse the whole history. Here is a screenshot of msysgit on the gjtapi repository: http://dickeradmin.de/resources/gjtapi-tortoisegit-browse.png About browsing the repository online with the webinterface - here is what sourceforge offers: http://flashup.git.sourceforge.net/git/gitweb.cgi?p=flashup/flashup;a=summary http://flashup.git.sourceforge.net/git/gitweb.cgi?p=flashup/flashup;a=tree You can get the converted repository here: http://dickeradmin.de/resources/gjtapi.git.zip I hope you'll take a look at it. I can't say too much about the 1.9 release. I'm still on 1.8. Cheers, JBoesl (pal) -------- Original-Nachricht -------- > Datum: Fri, 23 Sep 2011 08:11:55 -0400 > Von: Richard Deadman <rde...@de...> > An: gjt...@li... > Betreff: Re: [Gjtapi-developers] Switch vcs? > Tim, Johannes, > > Sorry for diving into an old conversation. I must say I only have a > high-level knowledge of Git. Would we lose code history if we switched > to Git? Can we move our trunk and 1.4 branch both over to Git? Can users > browse the Git code through the sourceforge web interface as they can > now? > > Another developer (Ralph Mack) has recently joined the project and he is > interested in the 1.4 branch and rebasing the recent changes from the > trunk onto this branch. > > He also raised a good question: our least release was 1.9RC4 from July > 2010. Should we release the final 1.9 or start a new 2.0 release? > > Cheers, > > > Richard > > > On Mon, 2011-07-25 at 17:11 +0100, Tim Panton wrote: > > I'm getting quite fond of git. > > I'm not sure how much is actually abandoned, but drawing a distinction > between experiments and real code > > might be useful. > > > > Tim. > > > > On 25 Jul 2011, at 14:02, Johannes Boesl wrote: > > > > > Hi there, > > > > > > I just had a hard time getting the sources through cvs. I'd like to > refactor a few things and maybe upgrade the asteriskprovider but it's just so > difficult with cvs. Besides there is a lot of stuff in the repository > which seems abandoned to me. > > > So I'd propose to switch to another version control system? What do > you think? > > > Git has a lot of drive latley and I like it a lot too. Making it > easier for others to hack on the sources could give the project a bit more > attention too. There is also a converter from cvs to git which keeps the > versionhistory and the comments. > > > > > > I'm looking forward to reading your comments on this. > > > > > > With kind regards, > > > JBoesl (pal) > > > -- > > > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! > > > Jetzt informieren: http://www.gmx.net/de/go/freephone > > > > > > > ------------------------------------------------------------------------------ > > > Storage Efficiency Calculator > > > This modeling tool is based on patent-pending intellectual property > that > > > has been used successfully in hundreds of IBM storage optimization > engage- > > > ments, worldwide. Store less, Store more with what you own, Move data > to > > > the right place. Try It Now! > http://www.accelacomm.com/jaw/sfnl/114/51427378/ > > > _______________________________________________ > > > Gjtapi-developers mailing list > > > Gjt...@li... > > > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers > > > > > > > ------------------------------------------------------------------------------ > > Storage Efficiency Calculator > > This modeling tool is based on patent-pending intellectual property that > > has been used successfully in hundreds of IBM storage optimization > engage- > > ments, worldwide. Store less, Store more with what you own, Move data > to > > the right place. Try It Now! > http://www.accelacomm.com/jaw/sfnl/114/51427378/ > > _______________________________________________ > > Gjtapi-developers mailing list > > Gjt...@li... > > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers > > -- > Richard Deadman > Deadman Consulting Inc. > mailto:rde...@de... > 613-220-2469 > http://www.deadman.ca > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > _______________________________________________ > Gjtapi-developers mailing list > Gjt...@li... > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de |
|
From: Richard D. <rde...@de...> - 2011-09-23 12:36:03
|
Tim, Johannes, Sorry for diving into an old conversation. I must say I only have a high-level knowledge of Git. Would we lose code history if we switched to Git? Can we move our trunk and 1.4 branch both over to Git? Can users browse the Git code through the sourceforge web interface as they can now? Another developer (Ralph Mack) has recently joined the project and he is interested in the 1.4 branch and rebasing the recent changes from the trunk onto this branch. He also raised a good question: our least release was 1.9RC4 from July 2010. Should we release the final 1.9 or start a new 2.0 release? Cheers, Richard On Mon, 2011-07-25 at 17:11 +0100, Tim Panton wrote: > I'm getting quite fond of git. > I'm not sure how much is actually abandoned, but drawing a distinction between experiments and real code > might be useful. > > Tim. > > On 25 Jul 2011, at 14:02, Johannes Boesl wrote: > > > Hi there, > > > > I just had a hard time getting the sources through cvs. I'd like to refactor a few things and maybe upgrade the asteriskprovider but it's just so difficult with cvs. Besides there is a lot of stuff in the repository which seems abandoned to me. > > So I'd propose to switch to another version control system? What do you think? > > Git has a lot of drive latley and I like it a lot too. Making it easier for others to hack on the sources could give the project a bit more attention too. There is also a converter from cvs to git which keeps the versionhistory and the comments. > > > > I'm looking forward to reading your comments on this. > > > > With kind regards, > > JBoesl (pal) > > -- > > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! > > Jetzt informieren: http://www.gmx.net/de/go/freephone > > > > ------------------------------------------------------------------------------ > > Storage Efficiency Calculator > > This modeling tool is based on patent-pending intellectual property that > > has been used successfully in hundreds of IBM storage optimization engage- > > ments, worldwide. Store less, Store more with what you own, Move data to > > the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ > > _______________________________________________ > > Gjtapi-developers mailing list > > Gjt...@li... > > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers > > > ------------------------------------------------------------------------------ > Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that > has been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Gjtapi-developers mailing list > Gjt...@li... > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers -- Richard Deadman Deadman Consulting Inc. mailto:rde...@de... 613-220-2469 http://www.deadman.ca |
|
From: Tim P. <th...@we...> - 2011-07-25 16:51:02
|
I'm getting quite fond of git. I'm not sure how much is actually abandoned, but drawing a distinction between experiments and real code might be useful. Tim. On 25 Jul 2011, at 14:02, Johannes Boesl wrote: > Hi there, > > I just had a hard time getting the sources through cvs. I'd like to refactor a few things and maybe upgrade the asteriskprovider but it's just so difficult with cvs. Besides there is a lot of stuff in the repository which seems abandoned to me. > So I'd propose to switch to another version control system? What do you think? > Git has a lot of drive latley and I like it a lot too. Making it easier for others to hack on the sources could give the project a bit more attention too. There is also a converter from cvs to git which keeps the versionhistory and the comments. > > I'm looking forward to reading your comments on this. > > With kind regards, > JBoesl (pal) > -- > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! > Jetzt informieren: http://www.gmx.net/de/go/freephone > > ------------------------------------------------------------------------------ > Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that > has been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > Gjtapi-developers mailing list > Gjt...@li... > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers |
|
From: Johannes B. <B0...@gm...> - 2011-07-25 13:02:23
|
Hi there, I just had a hard time getting the sources through cvs. I'd like to refactor a few things and maybe upgrade the asteriskprovider but it's just so difficult with cvs. Besides there is a lot of stuff in the repository which seems abandoned to me. So I'd propose to switch to another version control system? What do you think? Git has a lot of drive latley and I like it a lot too. Making it easier for others to hack on the sources could give the project a bit more attention too. There is also a converter from cvs to git which keeps the versionhistory and the comments. I'm looking forward to reading your comments on this. With kind regards, JBoesl (pal) -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone |
|
From: Mark B. <mar...@ib...> - 2010-11-11 14:59:21
|
Hello all Has anyone had any experience with JTAPI and Nortel? I have a simple GJTapi discovery service running locally (XP) which detects a multitude of services (Including Tapi3). I have a Nortel BCM 50 on the network and I have connected my machine to the BCM 50 with the Nortel LAN CTE Client so that listed as one of the telephony providers on my machine there is an entry "Business Communications Manager TAPI Service Provider". All good so far. My next step is make the BCM 50 place a call from a handset on the network to an external line, I think I have done all the groundwork but cant seem to get the system to want to play. With regards, Mark Benussi, IBT Services mar...@ib... Tel +44 2392 754635 Mob +44 7714 767407 Fax +44 7092 094490 <http://www.ibt.com/> ________________________________ This communication and any attachments contain information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received this communication in error, please return it with the title "Received in error" to mar...@ib... then delete the email and destroy any copies of it. E-mail communications cannot be guaranteed to be secure or error free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept liability for any such matters or their consequences. Anyone who communicates with us by e-mail is taken to accept the risks in doing so. |
|
From: Richard D. <rde...@de...> - 2010-05-04 21:05:06
|
I have uploaded files for release 1.9-rc3 to sourceforge. It is missing the JTAPI 1.4 core -- I need to merge the trunk changes into the branch for this. I did add about 170 unit tests to the codebase this past week and found a few minor bugs. If no significant bugs are reported, I will promote to a full 1.9 release in two weeks. Cheers, Richard On 4/27/2010 3:44 AM, Dr. Dirk Schnelle-Walka wrote: > Hi Richard, > > this sounds like a plan ;-) > > I think that this should be the way to go. > > Dirk > > >> -----Original Message----- >> From: Richard Deadman [mailto:rde...@de...] >> Sent: Monday, April 26, 2010 9:01 PM >> To: gjt...@li... >> Subject: Re: [Gjtapi-developers] Next GJTAPI version? >> >> I saw it as a chance for the community to test it, since there are a >> number of new features. While we need more unit tests, it is hard to >> fully unit test the framework since it is so dependent on state >> machines >> and listeners. If no significant bugs were reported from the release >> candidate, then we would create a full 1.9 release. >> >> That was my intention, anyway. >> >> >> Richard >> >> On 4/26/2010 2:06 PM, Dr. Dirk Schnelle-Walka wrote: >> >>> It depends on what you think about this release. 1.9-rc3 would mean >>> >> that >> >>> there is still something to come to make it a full release. 1.9 means >>> that this is a stable and tested build. >>> >>> So what is missing to make it 1.9? >>> >>> b.t.w: There is one more change. I enhanced the demo to be more >>> >> general. >> >>> Dirk >>> >>> >>> >>> >>>> Nice. It's always good to hear progress is done. >>>> >>>> I'd vote for the first suggestion: 1.9-rc3 >>>> >>>> >>>> -------- Original-Nachricht -------- >>>> >>>> >>>>> Datum: Mon, 26 Apr 2010 10:48:15 -0400 >>>>> Von: Richard Deadman<rde...@de...> >>>>> An: gjt...@li... >>>>> Betreff: [Gjtapi-developers] Next GJTAPI version? >>>>> >>>>> >>>> >>>>> I've recently done some work on GJTAPI and thought it was time for >>>>> >> a new >> >>>>> release. Our last release was 1.9-rc1 (release candidate 1) in July >>>>> 2008, but that was never followed up with a full 1.9 release, do >>>>> >> mostly >> >>>>> to laziness. 1.8 is still marked as our last official production >>>>> >> release. >> >>>>> Since 1.9-rc1, the following has been added: >>>>> >>>>> * Refactoring by Dirk Schnelle-Walka >>>>> * Addition of JAX-WS web server provider >>>>> * Allowing Tapi3 DLL location to be specified in config file >>>>> * Unit tests >>>>> * Moving to generic collections for most of the core packages >>>>> * Removal of many warnings in core (which allowed for a few >>>>> >> code >> >>>>> fixes) >>>>> * njiax-1.9-rc2 provider >>>>> * memory leak in TAPI3 DLL >>>>> * Many other fixes >>>>> >>>>> What should we name the next release: >>>>> >>>>> * 1.9-rc3 >>>>> * 1.9 >>>>> * 1.10-rc1 >>>>> * 1.10 >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> Richard >>>>> >>>>> -- >>>>> Richard Deadman >>>>> Deadman Consulting, Inc. >>>>> Web Services, Policy Management, Java Telephony, Software >>>>> >> Architecture >> >>>>> mailto:rde...@de... >>>>> http://www.deadman.ca >>>>> Cell: 613-220-2469 >>>>> >>>>> >>>>> >>>> >>> --------------------------------------------------------------------- >>> >> --------- >> >>> _______________________________________________ >>> Gjtapi-developers mailing list >>> Gjt...@li... >>> https://lists.sourceforge.net/lists/listinfo/gjtapi-developers >>> >>> >>> >>> >> -- >> Richard Deadman >> Deadman Consulting, Inc. >> Web Services, Policy Management, Java Telephony, Software Architecture >> mailto:rde...@de... >> http://www.deadman.ca >> Cell: 613-220-2469 >> >> >> ----------------------------------------------------------------------- >> ------- >> _______________________________________________ >> Gjtapi-developers mailing list >> Gjt...@li... >> https://lists.sourceforge.net/lists/listinfo/gjtapi-developers >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Gjtapi-developers mailing list > Gjt...@li... > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers > > > -- Richard Deadman Deadman Consulting, Inc. Web Services, Policy Management, Java Telephony, Software Architecture mailto:rde...@de... http://www.deadman.ca Cell: 613-220-2469 |
|
From: Dr. D. Schnelle-W. <dir...@jv...> - 2010-04-27 07:44:58
|
Hi Richard, this sounds like a plan ;-) I think that this should be the way to go. Dirk > -----Original Message----- > From: Richard Deadman [mailto:rde...@de...] > Sent: Monday, April 26, 2010 9:01 PM > To: gjt...@li... > Subject: Re: [Gjtapi-developers] Next GJTAPI version? > > I saw it as a chance for the community to test it, since there are a > number of new features. While we need more unit tests, it is hard to > fully unit test the framework since it is so dependent on state > machines > and listeners. If no significant bugs were reported from the release > candidate, then we would create a full 1.9 release. > > That was my intention, anyway. > > > Richard > > On 4/26/2010 2:06 PM, Dr. Dirk Schnelle-Walka wrote: > > It depends on what you think about this release. 1.9-rc3 would mean > that > > there is still something to come to make it a full release. 1.9 means > > that this is a stable and tested build. > > > > So what is missing to make it 1.9? > > > > b.t.w: There is one more change. I enhanced the demo to be more > general. > > > > Dirk > > > > > > > >> Nice. It's always good to hear progress is done. > >> > >> I'd vote for the first suggestion: 1.9-rc3 > >> > >> > >> -------- Original-Nachricht -------- > >> > >>> Datum: Mon, 26 Apr 2010 10:48:15 -0400 > >>> Von: Richard Deadman<rde...@de...> > >>> An: gjt...@li... > >>> Betreff: [Gjtapi-developers] Next GJTAPI version? > >>> > >> > >>> I've recently done some work on GJTAPI and thought it was time for > a new > >>> release. Our last release was 1.9-rc1 (release candidate 1) in July > >>> 2008, but that was never followed up with a full 1.9 release, do > mostly > >>> to laziness. 1.8 is still marked as our last official production > release. > >>> > >>> Since 1.9-rc1, the following has been added: > >>> > >>> * Refactoring by Dirk Schnelle-Walka > >>> * Addition of JAX-WS web server provider > >>> * Allowing Tapi3 DLL location to be specified in config file > >>> * Unit tests > >>> * Moving to generic collections for most of the core packages > >>> * Removal of many warnings in core (which allowed for a few > code > >>> fixes) > >>> * njiax-1.9-rc2 provider > >>> * memory leak in TAPI3 DLL > >>> * Many other fixes > >>> > >>> What should we name the next release: > >>> > >>> * 1.9-rc3 > >>> * 1.9 > >>> * 1.10-rc1 > >>> * 1.10 > >>> > >>> Cheers, > >>> > >>> > >>> Richard > >>> > >>> -- > >>> Richard Deadman > >>> Deadman Consulting, Inc. > >>> Web Services, Policy Management, Java Telephony, Software > Architecture > >>> mailto:rde...@de... > >>> http://www.deadman.ca > >>> Cell: 613-220-2469 > >>> > >>> > >> > > > > --------------------------------------------------------------------- > --------- > > _______________________________________________ > > Gjtapi-developers mailing list > > Gjt...@li... > > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers > > > > > > > > -- > Richard Deadman > Deadman Consulting, Inc. > Web Services, Policy Management, Java Telephony, Software Architecture > mailto:rde...@de... > http://www.deadman.ca > Cell: 613-220-2469 > > > ----------------------------------------------------------------------- > ------- > _______________________________________________ > Gjtapi-developers mailing list > Gjt...@li... > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers |
|
From: Richard D. <rde...@de...> - 2010-04-26 19:01:13
|
I saw it as a chance for the community to test it, since there are a number of new features. While we need more unit tests, it is hard to fully unit test the framework since it is so dependent on state machines and listeners. If no significant bugs were reported from the release candidate, then we would create a full 1.9 release. That was my intention, anyway. Richard On 4/26/2010 2:06 PM, Dr. Dirk Schnelle-Walka wrote: > It depends on what you think about this release. 1.9-rc3 would mean that > there is still something to come to make it a full release. 1.9 means > that this is a stable and tested build. > > So what is missing to make it 1.9? > > b.t.w: There is one more change. I enhanced the demo to be more general. > > Dirk > > > >> Nice. It's always good to hear progress is done. >> >> I'd vote for the first suggestion: 1.9-rc3 >> >> >> -------- Original-Nachricht -------- >> >>> Datum: Mon, 26 Apr 2010 10:48:15 -0400 >>> Von: Richard Deadman<rde...@de...> >>> An: gjt...@li... >>> Betreff: [Gjtapi-developers] Next GJTAPI version? >>> >> >>> I've recently done some work on GJTAPI and thought it was time for a new >>> release. Our last release was 1.9-rc1 (release candidate 1) in July >>> 2008, but that was never followed up with a full 1.9 release, do mostly >>> to laziness. 1.8 is still marked as our last official production release. >>> >>> Since 1.9-rc1, the following has been added: >>> >>> * Refactoring by Dirk Schnelle-Walka >>> * Addition of JAX-WS web server provider >>> * Allowing Tapi3 DLL location to be specified in config file >>> * Unit tests >>> * Moving to generic collections for most of the core packages >>> * Removal of many warnings in core (which allowed for a few code >>> fixes) >>> * njiax-1.9-rc2 provider >>> * memory leak in TAPI3 DLL >>> * Many other fixes >>> >>> What should we name the next release: >>> >>> * 1.9-rc3 >>> * 1.9 >>> * 1.10-rc1 >>> * 1.10 >>> >>> Cheers, >>> >>> >>> Richard >>> >>> -- >>> Richard Deadman >>> Deadman Consulting, Inc. >>> Web Services, Policy Management, Java Telephony, Software Architecture >>> mailto:rde...@de... >>> http://www.deadman.ca >>> Cell: 613-220-2469 >>> >>> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Gjtapi-developers mailing list > Gjt...@li... > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers > > > -- Richard Deadman Deadman Consulting, Inc. Web Services, Policy Management, Java Telephony, Software Architecture mailto:rde...@de... http://www.deadman.ca Cell: 613-220-2469 |
|
From: Dr. D. Schnelle-W. <dir...@jv...> - 2010-04-26 18:07:16
|
It depends on what you think about this release. 1.9-rc3 would mean that there is still something to come to make it a full release. 1.9 means that this is a stable and tested build. So what is missing to make it 1.9? b.t.w: There is one more change. I enhanced the demo to be more general. Dirk > Nice. It's always good to hear progress is done. > > I'd vote for the first suggestion: 1.9-rc3 > > > -------- Original-Nachricht -------- >> Datum: Mon, 26 Apr 2010 10:48:15 -0400 >> Von: Richard Deadman<rde...@de...> >> An: gjt...@li... >> Betreff: [Gjtapi-developers] Next GJTAPI version? > >> I've recently done some work on GJTAPI and thought it was time for a new >> release. Our last release was 1.9-rc1 (release candidate 1) in July >> 2008, but that was never followed up with a full 1.9 release, do mostly >> to laziness. 1.8 is still marked as our last official production release. >> >> Since 1.9-rc1, the following has been added: >> >> * Refactoring by Dirk Schnelle-Walka >> * Addition of JAX-WS web server provider >> * Allowing Tapi3 DLL location to be specified in config file >> * Unit tests >> * Moving to generic collections for most of the core packages >> * Removal of many warnings in core (which allowed for a few code >> fixes) >> * njiax-1.9-rc2 provider >> * memory leak in TAPI3 DLL >> * Many other fixes >> >> What should we name the next release: >> >> * 1.9-rc3 >> * 1.9 >> * 1.10-rc1 >> * 1.10 >> >> Cheers, >> >> >> Richard >> >> -- >> Richard Deadman >> Deadman Consulting, Inc. >> Web Services, Policy Management, Java Telephony, Software Architecture >> mailto:rde...@de... >> http://www.deadman.ca >> Cell: 613-220-2469 >> > |
|
From: Johannes B. <B0...@gm...> - 2010-04-26 15:30:41
|
Nice. It's always good to hear progress is done. I'd vote for the first suggestion: 1.9-rc3 -------- Original-Nachricht -------- > Datum: Mon, 26 Apr 2010 10:48:15 -0400 > Von: Richard Deadman <rde...@de...> > An: gjt...@li... > Betreff: [Gjtapi-developers] Next GJTAPI version? > I've recently done some work on GJTAPI and thought it was time for a new > release. Our last release was 1.9-rc1 (release candidate 1) in July > 2008, but that was never followed up with a full 1.9 release, do mostly > to laziness. 1.8 is still marked as our last official production release. > > Since 1.9-rc1, the following has been added: > > * Refactoring by Dirk Schnelle-Walka > * Addition of JAX-WS web server provider > * Allowing Tapi3 DLL location to be specified in config file > * Unit tests > * Moving to generic collections for most of the core packages > * Removal of many warnings in core (which allowed for a few code > fixes) > * njiax-1.9-rc2 provider > * memory leak in TAPI3 DLL > * Many other fixes > > What should we name the next release: > > * 1.9-rc3 > * 1.9 > * 1.10-rc1 > * 1.10 > > Cheers, > > > Richard > > -- > Richard Deadman > Deadman Consulting, Inc. > Web Services, Policy Management, Java Telephony, Software Architecture > mailto:rde...@de... > http://www.deadman.ca > Cell: 613-220-2469 > -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 |
|
From: Richard D. <rde...@de...> - 2010-04-26 15:15:14
|
I've recently done some work on GJTAPI and thought it was time for a new
release. Our last release was 1.9-rc1 (release candidate 1) in July
2008, but that was never followed up with a full 1.9 release, do mostly
to laziness. 1.8 is still marked as our last official production release.
Since 1.9-rc1, the following has been added:
* Refactoring by Dirk Schnelle-Walka
* Addition of JAX-WS web server provider
* Allowing Tapi3 DLL location to be specified in config file
* Unit tests
* Moving to generic collections for most of the core packages
* Removal of many warnings in core (which allowed for a few code fixes)
* njiax-1.9-rc2 provider
* memory leak in TAPI3 DLL
* Many other fixes
What should we name the next release:
* 1.9-rc3
* 1.9
* 1.10-rc1
* 1.10
Cheers,
Richard
--
Richard Deadman
Deadman Consulting, Inc.
Web Services, Policy Management, Java Telephony, Software Architecture
mailto:rde...@de...
http://www.deadman.ca
Cell: 613-220-2469
|
|
From: <rde...@de...> - 2009-05-19 00:38:30
|
Dirk, Thanks. On the test front, we have ant scripts that package up the release and separate out packages appropriately. For instance, we now package up individual providers separately so that users do not have to download them all. I believe the test subpackages are separated out this way -- if not, this can easily be done. Cheers, Richard -- Richard Deadman Deadman Consulting Inc. mailto:rde...@de... 613-220-2469 http://www.deadman.ca Quoting "Dr. Dirk Schnelle-Walka" <dir...@jv...>: > Hi, > > I just committed my changes. The new concept was applied to the > sipprovider. I tested it with the demo GUI and it seems to work. >> Dirk, >> >> Okay, I understand better now. I see the benefit and understand how it >> could be implemented to not affect existing raw providers. Please go >> ahead. >> >> A side note: I got a message from the email list that your message was >> blocked due to the size of the attachments. I tried to release it but >> have misplaced my moderator's password. If anyone wants to see the >> diagrams Dirk produced, let me know. Perhaps they could be added to >> the documentation, such as it is. >> > Another one: > I saw a package net.sourceforge.gjtapi.test (and subpackages). IMHO they > should be moved to a distinct test source directory. I already > introduced one for some unit tests for the protocols. I am not sure if > these are unit tests, system tests or something else. > > However, the goal should be not to have those classes in the binary > distribution. > > > ~dirk > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Gjtapi-developers mailing list > Gjt...@li... > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers > |
|
From: Dr. D. Schnelle-W. <dir...@jv...> - 2009-05-16 06:10:15
|
Hi, I just committed my changes. The new concept was applied to the sipprovider. I tested it with the demo GUI and it seems to work. > Dirk, > > Okay, I understand better now. I see the benefit and understand how it > could be implemented to not affect existing raw providers. Please go > ahead. > > A side note: I got a message from the email list that your message was > blocked due to the size of the attachments. I tried to release it but > have misplaced my moderator's password. If anyone wants to see the > diagrams Dirk produced, let me know. Perhaps they could be added to > the documentation, such as it is. > Another one: I saw a package net.sourceforge.gjtapi.test (and subpackages). IMHO they should be moved to a distinct test source directory. I already introduced one for some unit tests for the protocols. I am not sure if these are unit tests, system tests or something else. However, the goal should be not to have those classes in the binary distribution. ~dirk |
|
From: <rde...@de...> - 2009-05-13 16:31:55
|
Dirk, Okay, I understand better now. I see the benefit and understand how it could be implemented to not affect existing raw providers. Please go ahead. A side note: I got a message from the email list that your message was blocked due to the size of the attachments. I tried to release it but have misplaced my moderator's password. If anyone wants to see the diagrams Dirk produced, let me know. Perhaps they could be added to the documentation, such as it is. Richard -- Richard Deadman Deadman Consulting Inc. mailto:rde...@de... 613-220-2469 http://www.deadman.ca Quoting "Dr. Dirk Schnelle-Walka" <dir...@jv...>: > Hi Richard, > > >> If I understand you correctly, we would introduce a new >> ResourceFinder interface and then the >> GenericGjtapiPeer.GetProvider() method would: >> - determine the raw provider >> - find the properties for the raw provider >> - instantiate the raw provider >> - (modified)call "initialize(Properties, ResourceFinder)" on the >> raw provider with the callback ResourceFinder handle back to the >> GjtapiProvider so that the raw provider can call back and find more >> resources leveraging the peer. >> >> > Yes, that was the basic idea behind it. > > >> Two other options are: >> >> (Existing) >> - determine the raw provider >> - find the properties for the raw provider >> - instantiate the raw provider >> - call "initialize()" on the raw provider with the properties >> - The raw provider than loads up any addition resources internally >> >> (New interface optionally implemented by raw providers) >> - determine the raw provider >> - find the properties for the raw provider >> - instantiate the raw provider >> - (new) see if the raw provider implements ResourceFinder. If it >> does, use its findResource() method to load more resources. >> - call "initialize()" on the raw provider with the combined >> properties from the configuration file and the raw provider's >> resource finder. >> >> This has the advantage of not affecting existing raw providers. >> >> >> As you note, the existing framework requires that the raw provider >> look up the additional properties in its implementation of the >> "initialize()" method. It can then use the entries in the existing >> properties file to bootstrap its lookup of relative properties >> (i.e. using port number or database connection string). >> >> I'm not opposed to adding a new interface and changing APIs, but >> I'm trying to understand what the value is. Is the idea that the >> raw provider can determine the relative property location and then >> leverage the existing framework to load up the properties from >> this relative location? One downside is that we break backwards >> compatibility with existing raw providers outside of our project. >> > That was my intention. The current implementation forces the raw > providers to implement their own lookup with all their locl errors and > all their custom configuration specials. > > The basic idea was to have a centralized findResource method as it is > already in the peer class, so there must be a callback from the > resource provider to the ResourceFinder. You have to consider that the > raw provider may want to instantiate multiple objects (phones) with > different values for the same property name, so a Map would not be > sufficient to feed the raw provider with additional settings. > > I can understand that you do not want to break backwards compatibility, > so we should not add an extra parameter to the existing providers. I > attached some figures to show what I am talking about and how a > solution may look like. > > ~dirk |
|
From: <rde...@de...> - 2009-05-12 13:13:23
|
Dirk, If I understand you correctly, we would introduce a new ResourceFinder interface and then the GenericGjtapiPeer.GetProvider() method would: - determine the raw provider - find the properties for the raw provider - instantiate the raw provider - (modified)call "initialize(Properties, ResourceFinder)" on the raw provider with the callback ResourceFinder handle back to the GjtapiProvider so that the raw provider can call back and find more resources leveraging the peer. Two other options are: (Existing) - determine the raw provider - find the properties for the raw provider - instantiate the raw provider - call "initialize()" on the raw provider with the properties - The raw provider than loads up any addition resources internally (New interface optionally implemented by raw providers) - determine the raw provider - find the properties for the raw provider - instantiate the raw provider - (new) see if the raw provider implements ResourceFinder. If it does, use its findResource() method to load more resources. - call "initialize()" on the raw provider with the combined properties from the configuration file and the raw provider's resource finder. This has the advantage of not affecting existing raw providers. As you note, the existing framework requires that the raw provider look up the additional properties in its implementation of the "initialize()" method. It can then use the entries in the existing properties file to bootstrap its lookup of relative properties (i.e. using port number or database connection string). I'm not opposed to adding a new interface and changing APIs, but I'm trying to understand what the value is. Is the idea that the raw provider can determine the relative property location and then leverage the existing framework to load up the properties from this relative location? One downside is that we break backwards compatibility with existing raw providers outside of our project. Cheers, Richard -- Richard Deadman Deadman Consulting Inc. mailto:rde...@de... 613-220-2469 http://www.deadman.ca Quoting "Dr. Dirk Schnelle-Walka" <dir...@jv...>: > Hi Richard, > > I came across the problem that I have difficulties in reading a custom > configuration when the raw provider is initialized. > > Currently the initialze method is called with a map of properties that > are obtained from the provider's gjtapi configuration file. Some > providers, like sip or mjsip, need extra configuration files to set up > the distinct phones. Currently they do this by having a property in > their gjtapi configuration file that name the phone configuration file, > e.g., > > ProviderClass = net.sourceforge.gjtapi.raw.sipprovider.SipProvider > gjtapi.sip.sip_phone=sipphone1,sipphone2 > > Now we have the problem that the location of the siphonex property file > is relative to the path where the whole application is being calles but > not in the same directory as the gjtapi configuration file. And I think > that it is not a good idea to have the path info in here. > That's why we need the same mechanism here to locate the disitinct > property files. Currentyl this is being done by the private method > GenericJtapiPeer.findResource(String resourceName):InputStream > > I propsoe to introduce an interface ResouceFinder with that method > signature that is being passed as an extra parameter in the initialize > method. IMHO it is not relevant for the providers to know that the > GenericJtapiPeer provides this method. GenericJtapiPeer then implements > this interface. > > I hope that it was possible to follow my thoughts here. > > If you agree, I could do the required changes. IMHO this has no effect > on the implementations that use their own implementation to find the > configuration files. > > ~dirk > > > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Gjtapi-developers mailing list > Gjt...@li... > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers > |
|
From: Dr. D. Schnelle-W. <dir...@jv...> - 2009-05-12 07:30:31
|
Hi Richard, I came across the problem that I have difficulties in reading a custom configuration when the raw provider is initialized. Currently the initialze method is called with a map of properties that are obtained from the provider's gjtapi configuration file. Some providers, like sip or mjsip, need extra configuration files to set up the distinct phones. Currently they do this by having a property in their gjtapi configuration file that name the phone configuration file, e.g., ProviderClass = net.sourceforge.gjtapi.raw.sipprovider.SipProvider gjtapi.sip.sip_phone=sipphone1,sipphone2 Now we have the problem that the location of the siphonex property file is relative to the path where the whole application is being calles but not in the same directory as the gjtapi configuration file. And I think that it is not a good idea to have the path info in here. That's why we need the same mechanism here to locate the disitinct property files. Currentyl this is being done by the private method GenericJtapiPeer.findResource(String resourceName):InputStream I propsoe to introduce an interface ResouceFinder with that method signature that is being passed as an extra parameter in the initialize method. IMHO it is not relevant for the providers to know that the GenericJtapiPeer provides this method. GenericJtapiPeer then implements this interface. I hope that it was possible to follow my thoughts here. If you agree, I could do the required changes. IMHO this has no effect on the implementations that use their own implementation to find the configuration files. ~dirk |
|
From: Dr. D. Schnelle-W. <dir...@jv...> - 2009-04-21 14:32:19
|
Hi all, just FYI: I updated the demo to be more general. Now, the JtapiPeer.getServices() method is used to obtain a list of avialble providers. After selection of the provider you can also select the configured address. ~dirk |
|
From: Dr. D. Schnelle-W. <dir...@jv...> - 2009-03-04 11:11:20
|
Hi Richard, I just committed a piece of code to allow for playing and recording files using the URIs as described in MMAPI (using capture and playback). This way it should be possible to use the speaker as the output and the microphone as the input. The original code is from Renato. I just made some modifications. In order to use it you have to call the JVM with -Djava.protocol.handler.pkgs=net.sourceforge.gjtapi.protocols I hope that this is useful for somebody. ~dirk |
|
From: Dr. D. Schnelle-W. <dir...@jv...> - 2009-03-04 10:58:55
|
Hi Richard, I just committed a piece of code to allow for playing and recording files using the URIs as described in MMAPI (using capture and playback). This way it should be possible to use the speaker as the output and the microphone as the input. The original code is from Renato. I just made some modifications. In order to use it you have to call the JVM with -Djava.protocol.handler.pkgs=net.sourceforge.gjtapi.protocols I hope that this is useful for somebody. ~dirk |
|
From: Tim P. <th...@we...> - 2008-10-05 12:35:03
|
there was a very interesting discussion at astrodevcon last week about how to better support telephony frameworks with asterisk. I am hopeful that they will make a public API that makes our lives significantly easier. it is quite a ways off as yet. tim. Sent from my iPhone On Oct 5, 2008, at 11:18, "Johannes Boesl" <B0...@gm...> wrote: > Hi there, > > asterisk-jtapi is a different project so you might want to ask about > updateplans there. > However I tried to update the gjtapi-asterisk-provider recently but > it isn't as simple as I hoped. Currently it's in a very early stage > and I'm not actively working on it due to lack of spare time. I'll > post a message here on the mailinglist when it's done. I don't know > when that might be though. > > Cheers > > > >> Datum: Sun, 28 Sep 2008 17:14:16 +0200 >> Von: "Michele La Porta" <mic...@gm...> >> An: gjt...@li... >> Betreff: [Gjtapi-developers] asterisk 1.4 in roadmap? > >> Hi All, >> Is there plan to port asterisk-jtapi to work with asterisk 1.4.X >> using >> asterisk-java (nows it's org.asteriskjava packaging) and jtapi-1.4 ? >> >> Thanks >> >> -- >> Michele > > -- > Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten > Browser-Versionen downloaden: http://www.gmx.net/de/go/browser > > --- > ---------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gjtapi-developers mailing list > Gjt...@li... > https://lists.sourceforge.net/lists/listinfo/gjtapi-developers |
|
From: Johannes B. <B0...@gm...> - 2008-10-05 10:21:31
|
Hi there, asterisk-jtapi is a different project so you might want to ask about updateplans there. However I tried to update the gjtapi-asterisk-provider recently but it isn't as simple as I hoped. Currently it's in a very early stage and I'm not actively working on it due to lack of spare time. I'll post a message here on the mailinglist when it's done. I don't know when that might be though. Cheers > Datum: Sun, 28 Sep 2008 17:14:16 +0200 > Von: "Michele La Porta" <mic...@gm...> > An: gjt...@li... > Betreff: [Gjtapi-developers] asterisk 1.4 in roadmap? > Hi All, > Is there plan to port asterisk-jtapi to work with asterisk 1.4.X using > asterisk-java (nows it's org.asteriskjava packaging) and jtapi-1.4 ? > > Thanks > > -- > Michele -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser |
|
From: Michele La P. <mic...@gm...> - 2008-09-28 15:47:11
|
Hi Richard, Is there any plan to switch to maven2? I can help Michele > Folks, > > It's been a while since we've rolled the cvs code up into an official > build. I wanted to start putting this together but thought that I would > ask for some feedback from the group on development priorities. Some > ideas I have: > > * Change the build so that it consists of zip files that contain > both the GJTAPI jar and all required support jars (i.e. log4j or > SIP jars) and any native libraries. > * Break the build into a core package, that consists of the > framework as well as the emulator and maybe some of the bridge > providers, and provider packages, such as Asterisk or SIP. > * Package the JTAPI 1.4 based branch as an alternative core package. > * Change the provider detection code so that the user doesn't have > to modify the GenericResources.props file to tell the framework > about the existance of a provider on the classpath. I'm still > looking into this. If anyone has any ideas. > > Comments please. I know there is a new SIP provider by Renata in the > works. Anyone else have any work pending that we may want to base the > release on? > > Cheers, > > > Richard > > -- > Richard Deadman > Deadman Consulting, Inc. > Web Services, Policy Management, Java Telephony, Software Architecture > mailto:rdeadman@de... > http://www.deadman.ca > Office: 613-231-5112 > Cell: 613-220-2469 |
1 message has been excluded from this view by a project administrator.
