Caller ID Superfecta

My thoughts:

Database;
While I like to abstract all DB operation through my own simple light-weight functions, I generally don't like to use one-size-fits-all abstraction layers, like PEAR:DB, MDB, ADODB, etc. This sums up my thoughts on the subject pretty well.

If we are going to support only MySQL, we should target and optimize the code for MySQL. If we are going to support MySQL and SQLite3, then that is what we should target.

PHP version;
PHP 5+ or PHP 4.1+. Someone decide.

Jkiel,

Database¶

While I like that article you posted very much I don't think it can apply to FreePBX as a whole. The author states that database abstract is a waste of time because people wouldn't really be changing databases as it's a time consuming process, and while I agree with that it doesn't fit into the long term goals for freepbx.

The whole point of the database abstraction layer in FreePBX (Which is PearDB) is so that users can chose whatever database they want to use when they install FreePBX. I do know some users who use FreePBX that use Postgresql and Sqlite3. Right now Superfecta is "stuck" on mysql.

However, Upon looking at the code for FreePBX all of the query statements are written as pure mysql strings and never prepared (to use in something else), this leads me to believe that at one point FreePBX wanted to support other DB engines but kind of gave up hope. (which makes me wonder how the users on IRC are running FreePBX with Postresql.....)

Furthermore, when I think about it, who has really complained about Superfecta only supporting MySQL? (I can't think of one person). So I suppose it's a mute point, but I digress,

The thing that worries me is that superfecta gets it's database username & password by parsing amportal. As you know amportal.conf is being depreciated. The new format is freepbx.conf. It's a php file that contains php variables in the format that they would be sent to you if you used the freepbx hooks. Eg:

<?php
$amp_confg['AMPDBPASS'] = "amp109";

I'm not saying move away from how you are doing it now I just think we should avoid having to make multiple calls to the database. I haven't looked at the source for superfecta but I can only assume it opens the database once and then closes it once. I really hope it doesn't open and close the database a lot of times. Back in the days when Tony found endpoint manager someone had written every function in there to open and close mysql. When you were just VIEWING devices you'd have 10-20 connections openning and closing all at the same time. If superfecta doesn't do this then good. I just don't want it to continue to make lots of DB connections.

I guess what I'm saying is Mysql is all good. If we could pickup or use the already open database in freepbx that would be even better. But I don't know how you'd open it upon a call coming in as technically you aren't even going through freepbx at that point but instead you are going through asterisk alone.

PHP¶

Stick with php 5.x.x. Really if users have php 4 then they can use superfecta 2.x. We will always support that and im sure users will always come along to help with that project. Just don't add any more new features to 2.x.x. Start adding them to 3.x.x. Perhaps you could add the freepbx page hook that you did as a demo into some release of 2.x.x to get rid of people having maint/password wierdness isuess which would be a nice closing finish to adding new features to 2.x.x.

I'm afraid that us being tied to 4.x is going to hold this project back siginificantly in the future with all of the things you (jkiel) have been coming up with and thinking of. jacobs (can't remember his username right now) said you could also check source with the check syntax command which would be a great addition.

However, you can always say the recommended version is php 5.x.x, but we support php 4.1.x and disable/enable features like you said in some other threads. Perhaps have a class called sinlge-fork and a class called multi-fork. You load one or the other depending on what the PHP system is..

I say PHP 5.x.x, if you think it would be ok to support both php 5 and php 4, then say recommened version is php 5 but it will run just fine under php 5

What do you think of that?

3.x.x¶

This can be the first version that has turbo-results, meaning query multiple-sources at once. (I thought of calling it turbofecta for a second here, however that makes me laugh, I do like the name multifecta that you had). It will support the page hook (incoming routes) you did a month ago. It will have the new class system. It will have a better update engine (that doesn't rely on the "files" page of redmine). Maybe you can adjust the order of sources in the incoming routes page per route right there without ever having to go to the superfecta page. It will make coffee and solve every single PBX problem anyone could ever have.

Anyways thats my 2c. Tony is extremely busy all the time (and I'm not bashing him on that at all, it's good to be working) so I don't know if we will hear from him on this.

I'd like to get from igaetz and any other people who have something to say?

Perhaps a forum thread over at PBX in a Flash is in order to see what people want in v3?

jkiel wrote:

My thoughts:

Database; While I like to abstract all DB operation through my own simple light-weight functions, I generally don't like to use one-size-fits-all abstraction layers, like PEAR:DB, MDB, ADODB, etc. This sums up my thoughts on the subject pretty well.

If we are going to support only MySQL, we should target and optimize the code for MySQL. If we are going to support MySQL and SQLite3, then that is what we should target.

PHP version; PHP 5+ or PHP 4.1+. Someone decide.

I've updated my original reply significantly so please don't reply based on the email message.

First, to keep this discussion sane, we need to separate superfecta into different parts:

Superfecta Core (what is currently callerid.php, sources, etc.)
In 3.0, I would like to keep superfecta's core as independent as possible.

Superfecta UI (what is currently page.superfecta.php and sources.php)
I would like to move towards a more independent UI, however this will take more time, and there will always be system (FreePBX, etc.) specific elements. The first versions of 3.x will likely keep most of 2.x's UI.

Superfecta FreePBX Integration (install.php, functions.inc.php, etc.)
This is, of course, FreePBX specific.

Superfecta Asterisk Integration (superfecta.agi):
What Superfecta core needs to interface with Asterisk.

tm1000 wrote:

The thing that worries me is that superfecta gets it's database username & password by parsing amportal. As you know amportal.conf is being depreciated.

Yes. I was thinking about how to handle this, and I believe the best way may be to have something in "Superfecta FreePBX integration" write out a platform agnostic configuration file that "Superfecta core" will later use. Superfecta FreePBX Integration should have access to the DB information (credentials, etc.) without having to parse any files, right?

If we could pickup or use the already open database in freepbx that would be even better.

For Superfecta FreePBX integration and UI, sure, but for Superfecta Core, I have no desire to continue to use or depend on FreePBX, or a bloated abstraction layer. Superfecta core is executed and parsed far more often than FreePBX's UI -- just the thought of PearDB being parsed on each incoming call brings tears to my eyes.

My thought here is that we design with MySQL in mind, but try to keep it working with SQLite3. PostgreSQL does not support auto increment fields (well, it does in a way, but not in the same way as mysql as sqlite3), so I'm just crossing PostgreSQL off the list, punting it down the road for someone else to handle. I see many areas in FreePBX where PostgreSQL simply will not work -- so I can't imagine those that are currently using PostgreSQL with FreePBX are having any fun doing so.

I say PHP 5.x.x, if you think it would be ok to support both php 5 and php 4, then say recommened version is php 5 but it will run just fine under php 5

What do you think of that?

It would be easiest to cut all ties for PHP 4, and just move forward with PHP 5, however, I can see the case for supporting older PBX systems.

If we are going to support PHP 4.0.x, even in a limited way, it would be nice to find someone that can test it. Without any way to test, trying to support PHP 4 is a wasted effort.

So, I say 4.x support hinges on volunteers stepping up to test its code-path.

I've been thinking more on this.

While I hate bloated DB abstraction, I like the flexibility they bring. However, the overhead of PEARDB , ADODB, etc., is just too great. I've used PDO in the past, and have been pleased with its performance, since it's built into PHP since 5.1.0.

So, I guess it's a choice between:

1. Keeping compatibility with very old installations, but only being compatible with mysql, or,
2. Requiring PHP 5.1+, and opening the possibility for more DB support (initially only MYSQL will be targeted, but if test environments with SQLite, etc., are available they can be added as well). I suppose PEAR:PDO could be used for 5.0 compatibility -- but (see my thoughts on bloated abstraction layers)...

I vote for 2. I think it's the most forward looking for 3.x. For the past we have 2.2.x, and possibly 2.3.x.

Thoughts?

tm1000 wrote:

I'd like to get from igaetz and any other people who have something to say?

I am singularly unqualified to comment on this ticket, I am a Civil Engineer. My strength (if I can be said to have one) is more in the area of how the indvidual user interacts with the software or on the end result of the program. I am pretty clueless on the nuts and bolts.

I will venture the opinion that agrees nicely with tm1000, and that is I see no reason to support aging systems with CIDS 3.x. Anyone without the minimum requirements set forth for 3.x can avail themselves of the 2.x branch and get nearly the same utility. As has been pointed out repeatedly, PHP 5.x is not new (Wiki tells me that 5.0.0 was released in mid 2004! coming up on the 7th anniversary), and I think it is a bit unreasonable to maintain compatability that far back. Anyway that is my $0.02, vastly overcharged at that.

Something to note about this.

FreePBX is not going to support php4 in versions of 2.10 and higher. http://www.freepbx.org/trac/roadmap