On Feb 22, 2006, at 7:34 PM, Daniel Swarbrick wrote:
Overall, I'm right behind benjk's ideas (my preference being the XML
config files, although .plist looks manageable too), and look
forward to
working on them.
I am using Apple's Core Foundation (CF) framework to read/write those
files. The beauty of CF is that you don't actually have to settle for
one format. CF handles both XML plists and NeXT plaintext plists,
whichever you throw at it.
To allow cross-platform development Apple has released an open source
subset of CF called CF-Lite under BSD/MIT style license terms for use
on other *nix platforms and everything needed to read and write those
property lists is part of CF-Lite.
More info on CF-Lite can be found at ...
http://developer.apple.com/opensource/cflite.html
At the same time, I agree with Bartek that we need to draw a line
in the sand and push a stable version out the door, to attract some
more Asterisk users over here.
It's of course up to you but you may want to consider including this
in the original release.
For one, the changes involved are fairly minor because the CF/CF-Lite
framework does all the work. I am not doing any parsing at all, I am
only calling CF functions to return a value for a given key and
populate Asterisk's/OpenPBX's existing internal data structures with
those return values in the same way the Asterisk INI parser does.
Whilst the changes are minor, the benefits are significant and manyfold.
In fact, if legacy support, such as the ability to import or read INI
files is moved into a separate conversion utility or into a plug-in
module (ie. res_config_ini.so) then the core will actually be smaller
and leaner because config file parsing is no longer done in the core
itself.
Rest assured that Apple's CF and CF-Lite framework has several orders
of magnitude more quality assurance behind it than Asterisk's config
file parser and the chance that Digium's code will ever catch up is
even smaller than OBL getting elected president of the United States.
At the same time the changes I suggest here have a fairly large
potential to attract both new users and developers. This is because
the way configuration files are organised and formatted is largely
the equivalent of a GUI application's look and feel. Just like most
people will decide to try out a GUI app as a result of how the
screenshots appeal to them, the layout and syntax of configuration
files will often be the only thing that allows new users to compare
one server application with another.
Do people prefer postfix or exim over sendmail because they have a
more modern design and better security models? Or do they initially
choose them because sendmail configuration files look like alien
hieroglyphs when compared to postfix or exim configuration files? The
architectural benefits are most often seen as a nice-to-have item
which will only be appreciated and understood once the software has
been in use for some time. The original choice is most often largely
based on "how easy is it for me to learn to work this thing".
Consequently, I believe that a well structured and intuitive
configuration file system is a major factor in winning new users who
might otherwise choose Asterisk simply because it has got more momentum.
The impact of this will be higher if the very first release has a
different configuration file system than what Asterisk has got. It
would send a visible message along the lines of "we do things more
intuitively over here".
Further, the reason I am doing this in the first place is so I can
develop a nice GUI front end. Whilst it is not impossible to do that
on the basis of the INI format based configuration file system, it is
an order of magnitude harder and a lot more work. Even then, the
final result is likely to end up the way AMP has turned out. It's
alright as long as you don't try to do anything AMP doesn't do for
you and as long as you don't have to do any troubleshooting, but if
you need to go under the hood it's going to be messy and confusing.
The property list based configuration in combination with the CF/CF-
Lite framework will make the development of GUIs much easier.
Further, whatever the GUI does, it will always show up clean and
orderly on the property list level. Likewise you can edit your
configuration files manually and the GUI will be fully aware of
whatever changes or additions you have made.
For GUI developers this will make such a big difference that OpenPBX
will likely attract the attention of GUI developers who would
otherwise develop for Asterisk. The use of the CF-Lite framework
guarantees GUI developers that their GUI apps will always be using
the very same code to read and write configuration data as the server
itself. Yet unlike Asterisk's config file parser, the CF-Lite
framework doesn't require GUI developers to open source their apps if
they don't want to, which should attract commercial GUI developers.
All in all, I see the changes I suggested as a low effort - high
impact feature that can help OpenPBX to distinguish itself from
Asterisk.
regards
benjk
___________________________________________________________
Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com
_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev
