Re: [Bayonne-devel] web article about Bayonne

[David Sugar]

-----BEGIN PGP SIGNED MESSAGE-----
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

iD8DBQFCUpUuJlWtSTiTVsYRAp6xAJ9mOhKSJa71tY5C5ZfbmKGd3JNengCcCy2a
VTv21XsVto6pu0K4Oq56gmI=
=m5PI
-----END PGP SIGNATURE-----

dyfet.vcf
Description: Vcard