Re: [Bayonne-devel] web article about Bayonne

[David Sugar]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On the database front, I particularly like what I had done in the
ccscript3 engine, as it finally removes blocking during database connect
and disconnect.  It would not be hard at all to add a similar postgres
and mysql module back into that, and it has a much easier means of
testing since testing can be done externally from Bayonne.

I agree the 1.2.x branch has seen very worthwhile improvements, and
completely agree in regard to sip and h323 in regard to Bayonne.  I also
completely agree that what is done should be focused on keeping the
system essentially simple or even better simpler than it is today.

There is certainly room to further simpify and improve the existing
1.2.x releases (and better address some longstanding issues such as
database support), and I do think this should continue to be done,
though there is a lot of things in 1.2 that got put in which might be
simpler to leave alone as it's generally not used outside of the vpb
openswitch driver and yes, the core server works well even with that
stuff in there, rather than weeding those things out and then going back
fixing what might get broken as a result.  That is the more frustrating
part of the current 1.2 code base.  Understanding what Bayonne 1.2 would
be without those other complicated and ugly things in there suggests to
me what a cleaner and much simpler Bayonne 2.0 must be, and that is
where my current thoughts on radically simplifying Bayonne started from.

Julien Chavanton wrote:
>  
> 
> But I personally think that things are improving,
> 
> I have a running version that handle 40 000 calls/day.
> 
>  
> 
> I trust CommonC++2 & Ccscript, they seem to be bug free.
> 
> As long as this is reliable drivers should not be too hard to debug.
> 
>  
> 
>  
> 
> Features and expectation I am looking for:
> 
>  
> 
> -The multiple drivers support may be delayed.
> 
>  
> 
> -Even if we are working a lot on Globalcall this let us test the core of
> Bayonne in the mean time.
> 
>  
> 
> -I think H.323 and SIP will soon become more and more important I think
> Bayonne will be really interesting as an IVR VOIP server.
> 
>  
> 
> -Reliable Database support from Ccscript is a key feature, the one
> currently in Bayonne is still having bug, I have made my own and you
> know this is not something complex and does bring a lot of Interactivity
> possibility.
> 
>  
> 
>  
> 
> Conclusion, I think ?keep it simple? is the main lead we shall choose,
> there is already enough feature to debug.
> 
> If we can tell that most of the basic features are working as it is the
> case currently; Bayonne should be easier to start with and more people
> will start using it and help.
> 
> With the Lucas How-To it is now quite easy to install and configure Bayonne.
> 
>  
> 
> Any body is having problem with Dialogic Globalcall Drivers in Bayonne?
> 
>  
> 
> Julien
> 
>  
> 
>  
> 
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
> On Behalf Of David Sugar
> Sent: April 5, 2005 9:40 AM
> To: Ambar Roy
> Cc: address@hidden
> Subject: Re: [Bayonne-devel] web article about Bayonne
> 
>  
> 
> Hash: SHA1
> 
>  
> 
> I had been rather quiet because until very recently even I had not
> 
> reached any final decision on what we would be doing going forward.
> 
> Perhaps I have been quiet for far too long.
> 
>  
> 
> Originally we had some problems starting in 2003, when we had a party
> 
> interested in producing an analog phone system around voicetronix
> 
> hardware.  This resulted in a lot of time and interesting development
> 
> spent on that, but at the expensive of loosing focus on what Bayonne is
> 
> and on other things that would have been more valuable to people, such
> 
> as completing the then original openh323 driver that one contributor
> 
> started.  Of course, we later learned we could not use that original
> 
> openh323 driver anyway, because the person who submitted it later signed
> 
> agreements with another project which claimed ownership over his past work.
> 
>  
> 
> Around the start of 2004, new work was split into two trees, a testing
> 
> tree I started both to try and restore a better focus on what Bayonne
> 
> is, and based on new work and recommendations of people who were later
> 
> involved on the second tree.  This second tree was already then largely
> 
> complete, and included a new solid implementation of the openh323, and a
> 
> new aculab driver.  The aculab driver I had no means to test, and since
> 
> the new tree was being maintained and heavily tested internally by
> 
> others with such facilities, I agreed to promote that new tree as the
> 
> new stable release.  Given that, I modified the existing testing tree to
> 
> much more closely match the second stable tree, and bring the openh323
> 
> driver that I could test to match the second tree, to allow for wider
> 
> testing of the tree and at least of that new driver in the process, and
> 
> later as a place to get a sip driver going that could then easily
> 
> migrate back to the now similar future stable branch.
> 
>  
> 
> In that the second stable tree was essentially complete, I was asked to
> 
> discontinue the testing tree so as not to confuse users with two trees
> 
> with the introduction of the then promised release of the new stable
> 
> tree.  Of course around that time I also was sick part of 2004 with
> 
> Pneumonia, and afterward for other medical reasons, I could not travel
> 
> for much of the rest of last year.  Many of the normal events and
> 
> activities I do which involve Bayonne I was completely unable to perform
> 
> or attend.  I also moved, and I was kept very busy much of the remainder
> 
> of the year in other areas.  For the most part I was generally
> 
> unavailable to many people most of last year as a result.  For that I
> 
> assume full responsibility.  Of course, in that commitments were made to
> 
> me about introducing the new stable branch, and I completely trusted in
> 
> those commitments, I did not interfere in that process.  I had
> 
> considered appointing an interum maintainer as part of that release
> 
> which never happened.  As a result, nothing was accomplished in 2004.
> 
>  
> 
> As it was rather clear by the end of 2004 that those commitments were
> 
> not going to be fulfilled, I used what rather limited time I then had
> 
> available to work with a number of people who were maintaining existing
> 
> production sites, and particularly the excellent people at WS Wireless
> 
> in Bologna.  Together, we worked on changes needed to improve and better
> 
> support those using the last stable release, and bring it forward to
> 
> support current builds of Common C++ and other updated and bug-fixed
> 
> libraries, a process that continues to this day.  These changes were
> 
> limited either explicitly to specific bug fixes (particularly in the
> 
> dialogic drivers, which they use) and the completion of one feature that
> 
> was originally started in the testing branch; audio conferencing support
> 
> in the dialogic drivers.
> 
>  
> 
> As I found myself at the start of the year again the sole maintainer of
> 
> Bayonne, I had a number of possibilities going forward, and rather
> 
> limited time for any option I might choose.  Certainly the simplest
> 
> option would have been to discontinue Bayonne.  But I felt I could not
> 
> do that especially after the incredible help and support Aymeric gave me
> 
> early this year with the SIP driver, and with the continued support I do
> 
> get from people in the community, and we definitely do have one, such as
> 
> Luca, as well as that of people from companies like the WS Wireless
> 
> people, and Gerry Gilmore from Intel.
> 
>  
> 
> The first option going forward was to push the existing stable branch
> 
> forward and perhaps backport some other things from the testing branch.
> 
>  Of course, that branch had a lot of odd inconsistencies from the effort
> 
> put into supporting analog phone system cards and from the then rather
> 
> fluid nature of the ccscript core language itself.  It also suffers from
> 
> one other key Bayonne limitation; by pushing so much functionality down
> 
> to the driver, and with different people involved in initially creating
> 
> new drivers, each driver now has a very unique design pattern.  Hence,
> 
> each new driver added tends to exponentially add to the difficulties in
> 
> maintaining the system as a whole.  This is fine when each driver has
> 
> someone separate to maintain it, but becomes impossible when a large
> 
> number of the drivers have to be maintained without direct access to
> 
> every piece of hardware used, and where each driver must then be
> 
> verified for every change being made.
> 
>  
> 
> A second possibility would have been to promote and continue developing
> 
> the testing branch.  But while a lot of forward looking work was started
> 
> in it, all that was stopped and then abandoned last year, as it was
> 
> re-made to resemble the new stable branch that never appeared.  Hence,
> 
> many key limitations do remain unaddressed, and in some respects are
> 
> worse than even the stable branch, as it has a larger body of drivers
> 
> each with even more different design patterns.
> 
>  
> 
> The third option was to finally radically simplify Bayonne and refocus
> 
> on what it is supposed to actually do, much more so than what work was
> 
> in progress in the testing branch before being stopped.  As just one
> 
> example, while a lot of work had been done in the testing and missing
> 
> new stable release on loading multiple drivers, each driver maintained
> 
> in it's own way it's own managed timeslot segment of drivers, each coded
> 
> in their own way; instead, it would be much simpler to assign all loaded
> 
> drivers over a single contigues timeslot map, to have them all share
> 
> common base classes which run the same core state machine code, to have
> 
> all common audio processing peered in the common timeslot base rather
> 
> than implemented in very different ways in each driver, and to finally
> 
> have a common design pattern for all drivers, including for the
> 
> difficult process of handing off thread deaths out of the dying thread's
> 
> context, which is something that is done in a different and amazingly
> 
> complex way in each and every driver currently.  But this would take
> 
> some time, and even further freeze other activities until completed...
> 
>  
> 
> Ambar Roy wrote:
> 
>>>>I wrote an introduction to Bayonne and IVR services for the web megazine
> 
>>>>linuxfocus (http://www.linuxfocus.org)
> 
>>>> 
> 
>>>>it's in english:
> 
>>>
> 
>>> http://www.linuxfocus.org/English/April2005/article372.shtml
> 
>>>
> 
>>>>and italian: http://www.linuxfocus.org/Italiano/April2005/article372.shtml
> 
>>>> 
> 
>>>>the goal is, of course, to promote Bayonne's use in phone services
> 
>>>
> 
>>> Hi Luca,
> 
>>>
> 
>>> I read the english version. Excellent Article!
> 
>>>
> 
>>> I have been evaluating bayonne for some time and here are some reasons
> why I
> 
>>> am not being over enthausistic about using bayonne in production
> 
>>> environments:
> 
>>>
> 
>>> a. I hardly see any developer activity on bayonne. I have been a member of
> 
>>> bayonne-devel list for some time now and the message traffic is almost non
> 
>>> existant.
> 
>>>
> 
>>> b. I have seen that most people's queries on bayonne seem to go
> un-answered.
> 
>>>
> 
>>> c. I do not see any real community behind bayonne. I have been a member of
> 
>>> this list for the past 3 months and the only active members seem to be
> 
>>> yourself, David and Julien. What happened to everyone else?
> 
>>>
> 
>>> d. I have no clue as to how stable is bayonne's connectivity to telephone
> 
>>> networks via E1 links using PRI, R2 & C7/SS7 when using dialogic telephony
> 
>>> boards.
> 
>>>
> 
>>> e. What all features are available from the native scripting language used
> 
>>> in bayonne.
> 
>>>
> 
>>> f. No real description of successful implementation of bayonne in telecom
> 
>>> networks beyond "We are using bayonne!" or "We have successfully
> implemented
> 
>>> bayonne!"
> 
>>>
> 
>>> g. Is there any form of commercial support available for bayonne? Is it
> 
>>> possible that, if required, i can find people/companies who are willing to
> 
>>> work on getting rid of bugs or to implement new features for a fee?
> 
>>>
> 
>>> My company deploys high density IVR systems at telcos and currently we
> use a
> 
>>> proprietory platform for IVR systems. I have been trying to figure out if
> 
>>> bayonne is even a viable alternative to our current system! Our current
> 
>>> platform may be expensive and proprietory, but our vendor gives us
> excellent
> 
>>> support. Whenever we have faced any problems, our vendors have helped
> us big
> 
>>> time. I have never really felt confident about what would happen if I face
> 
>>> problems in a production environment. I have been following the bayonne
> 
>>> project for more than 1.5 years now, and I hardly see any activity. The
> 
>>> bayonne home pages are also not with any recent news. The bayonne.sf.net
> 
>>> page's latest news is from 27th Feb 2004 and on
> www.gnu.org/software/bayonne
> 
>>> the latest news item is from 2003-07-06!
> 
>>>
> 
>>> I really think that the bayonne project has not done much to attract people
> 
>>> who might be intrested in deploying bayonne in production environments.
> Luca
> 
>>> is doing a great job here, but we probably need more people doing similar
> 
>>> activity. Google tends to only turn up old articles on bayonne :-(
> 
>>>
> 
>>> Ambar Roy
> 
>>> PS: Luca bayonne.sourceforge.org does not lead to the bayonne page. It is
> 
>>> bayonne.sourceforge.net or bayonne.sf.net ;-)
> 
>>>
> 
>>>
> 
>>>
> 
>>> _______________________________________________
> 
>>> Bayonne-devel mailing list
> 
>>> address@hidden
> 
>>> http://lists.gnu.org/mailman/listinfo/bayonne-devel
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCUq80JlWtSTiTVsYRAuUlAJ9JthqkWRPk4txOCIXxW1lSuJGWHQCfQ3hN
gpHrfEv18wBkluR77UIMfzU=
=KIGD
-----END PGP SIGNATURE-----

dyfet.vcf
Description: Vcard