Peter
I certainly don't know what the fuss is about. Opal has
already really good
H.323 support but you cannot *make* people or *conjole*
people to migrate.
H.323 is a very low priority these days with a lot of
projects and many
projects may just want to continue their existing code base
then h323plus
will do that (aka Asterisk (chan_h323),GnuGk etc), others
like you are
indicating might want to migrate to opal to include SIP or
they might just
go off and get any one of the dozens and dozens of quality
SIP stacks out
there. There are others who are using their own SIP stack
who just want to
add a H.323 stack which might be opal or h323plus or even
ooh323.
h323plus exists because there is a need of it, all the new
work in h323plus
is MPL 1.1 so you don't have to worry about licensing
issues, want MPL ok,
what GPL ok too, just go cherry pick what you want and leave
whatever you
don't, I'm not fussy. If you want a bit of support for it,
then I'm willing
to assist with direct enquiries. If you don't think any of
it's relevent
then forget it even exists and just use whatever you are
using.
But saying I should do this and that.... Sure everyone wants
SIP so go use
openser or the dozens of other quality SIP stacks, if you
also need H.323
support use Asterisk or FreeSwitch or YATE or this little
great project
called Opal. Opal is a tiny small fish in a huge ocean. How
is me moving to
Opal going to change anything except cut off H.323 support
for some of the
bigger open source projects which relied on OpenH323 for
there support, sure
they can move to opal but honestly they'll probably just let
(like they have
been doing) their H.323 support stagnate. Just as with
Asterisk and GnuGK
I'm happy in assisting updating existing codebases from
openh323 to
h323plus. Easy, we went though the process last week with
both projects.
H323plus is meant to be project neutral (anyone can use it),
it's a drop in
replacement for openh323 and I still intend (where possible)
to be highly
compatible with opal so if your not ready to migrate then
h323plus or cannot
see a business case to do it, then it is there until you
decide to (if ever)
to migrate. You can pull out any of the new code and drop it
straight into
opal, I certainly will not be standing in anybodies way.
With respect to any other projects that may occur they will
be the same
format so they too will be a neutral stand alone project
library which
probably be more suited to the asterisk channel type model
rather than the
more integrated Opal model.
I really want to bring this whole discussion to an end. For
the majority of
people it has little relevence. For the rest, it is as it
is. let's move on.
Simon
-----Original Message-----
From: opalvoip-devel-bounces lists.sourceforge.net
[mailto:opalvoip-devel-bounceslists.sourceforge.net]On
Behalf Of Peter
Nixon
Sent: Saturday, 3 November 2007 11:13 PM
To: opalvoip-devellists.sourceforge.net
Cc: h323pluslists.packetizer.com; GNU Gatekeeper Developer;
Discussion
on enhancements and development issues with the OpenH323
library
Subject: Re: [Opalvoip-devel] [Openh323-devel] [h323plus]
opalvoip
vsh323plus
On Sat 03 Nov 2007, Peter Robinson wrote:
> Hi All,
>
> I've been a user of openh323/opal and on the mailings
lists since very
> early on when gnomemeeting was in the early 0.x
releases and have
> watched it all evolve, even contributing minor patches
and testing on
> ocasion.
>
> There are a number of things that disurb me about this
whole "we've
> been orphaned" deal.
>
> OPAL as it stands has been in development for years, it
was
> essentially openh323 version 2. Just like gnomemeeting
was renamed to
> ekiga to reflect the fact that it wasn't just aimed
solely at gnome,
> openh323's name was changed to reflect the fact that it
didn't just
> support h323, and as a result was essentially version
2. It was
> advertised as such for years.
>
> Simon there is certainly currently more development of
the SIP side of
> opal at the moment but I see that is the case for 2
reasons. firstly
> the H323 support was very stable and established, and
secondly the
> people doing the H323 development was being done one
openh323. The
> OPAL H323 side of things wouldn't stagnate as long as
there's
> developers. And if you and everyone else were to
develop on openh323
> version 2 (OPAL) there wouldn't be missing features
because you'd only
> have to do the work once. And the only reason the H323
features would
> stagnate is if the devs working on it and the
maintainers of the H323
> portion of the code (you and others) moved onto other
things. That
> would give everyone better features on all three
protocols currently
> supported... and any others that come along.
>
> I'm sure if the opal project had remained named
openh323 and called v2
> with new apis when they added sip support and later
renamed there
> wouldn't be this disparate uncessary separation and
code divergence
> and H323 would get nice features like the latest codecs
developed by
> craig, robert and co and SIP would get some of the
great features you
> and others develop for openh323 with very little
effort.
>
> This community is too small for all the in fighting
that I'm seen
> between all the various developers over the years. Way
more than a lot
> of the other projects I follow,
I was just reading through this thread over my Saturday
morning coffee and
thought I should write a reply. Then I got this this email
which very nicely
sumarises almost everything I wanted to say.
I do have one thing to add however. I have known both Simon
and Craig (and
the gnugk and ekiga people) for several years now and have
had the pleasure
of being involved in some spirited face to face discussions
over that time.
I respect you all and consider you all friends.
Simon, with that caveat, I would like to say that I think it
is a good thing
for h323plus to exist given the state of the openh323
"project" but I
heartily wish that its goal was more of a "maintenence
mode" project than an
actively developed alternative to OPAL. I have heard your
reasons for
continuing development on openh323/h323plus instead of OPAL
several times
before and I have to say that I was never fully convinced,
however recent
events have made me ever less sure.
Three months, I made the transition from owner of my own
company, to a new
position as RnD Director for a VoIP CPE vendor. This has
given me a
different perspective on things, given that I had always
been involved in
the "large" side of VoIP deployments where you
have gigabytes of disk space
and ram and a very different development environment, time
to market
requirements and market realities.
The fact is, despite incompatibilities, functionality gaps
and all wisdom to
the contrary, SIP is the current market standard for VoIP
CPEs.
If I told my CEO that I wanted to build a H.323 only CPE he
would tell me to
reconsider, or reconsider my position at the company. On the
other hand, if
I can build a SIP device, then deliver H.323 functionality
practically
for "free" by using OPAL then I can build either
an "advanced" model with
both SIP and H.323 support (It would cost more due to the
required flash and
ram increase), or an alternate H.323 firmware for the
"standard" device.
This, as H.323 proponent, is good for you, and this is a
major reason for me
to pick OPAL as the stack to develop on, otherwise I would
just as likely
pick one of the many other very good open source SIP stacks
available, and I
would never even consider doing the work to develop
completely independent
H.323 support using h323plus.
Please spend a moment to consider "new" users like
my company, and not only
the temporary difficulties that some old users (like gnugk
for example)
would face porting from openh323 to opal. The VoIP industry
is far from
done, and as you know, there are new protocols coming out
like AMS and
others which I hope one day will also be available as part
of OPAL also.
I think the decision to do new development in h323plus is a
little short
sighted, because it makes using your wonderfull new features
(and I really
mean that) difficult for new VoIP developers due to the
hurdle of learning
and using another library for H.323 in addition to whatever
library they
already use for SIP (Or IAX or AMS or whatever), and the
even bigger hurdle
of deciding to add H.323 support in the first place!
Consider also, what you will do when AMS is released.. You
will at some
point
outgrow the existing openh323 design and API and be forced
to refactor
things at which point you will likely end up with something
a lot like
OPAL 
Please, consider doing your future h323 development on OPAL!
I really
believe
that you will end up with a lot more people using your code
(and H.323) in
the long term.
--
Peter Nixon
http://peternixon.net/
------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Opalvoip-devel mailing list
Opalvoip-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opalvoip
-devel
------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Openh323-devel mailing list
Openh323-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openh323
-devel
|
> -----Original Message-----
> From: openh323-devel-bounceslists.sourceforge.net
[mailto:openh323-
> devel-bounceslists.sourceforge.net] On Behalf Of Simon
Horne
....
> I certainly don't know what the fuss is about.
The fuss is over dilution of effort. Taking up valuable
developer hours
porting from one to the other, multiple releases and bug
lists, and most
important the cross posting on lists!
> Opal has already
> really good
> H.323 support but you cannot *make* people or *conjole*
people to
> migrate.
Sure we cannot *make" people migrate, but what we can
do is make it
*attractive* for them to migrate. If everything new is in
OPAL, they will
make the effort. If we can get feedback from people we can
do whatever it
takes to make migration as easy as possible. The ultimate
goal would be just
to change the header files, add an OpalManager and
everything else will
"just work". It's never that easy, but that was
always the goal.
> H.323 is a very low priority these days with a lot of
projects and many
projects may just want to
....
There is a lot I just cut out which I think is quite
misinformed. But
arguing over details does not seem relevant in light of the
last paragraph.
> I really want to bring this whole discussion to an end.
For the
> majority of
> people it has little relevence. For the rest, it is as
it is. let's
> move on.
Very well. We cannot (nor should we be able to) stop you
from going your own
way. So, as I said in my first posting, I believe the
divergence will
continue and this makes me profoundly sad.
Robert Jongbloed
OPAL/OpenH323 Architect and Co-founder.
------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Openh323-devel mailing list
Openh323-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openh323
-devel
|
