Hi Shawn, First, let me assure you that I'm not asking when it will be done Just a few questions on the PHP/MySQL rewrite front: 1. Are you using ADODB to allow for database independence? http://adodb.sourceforge.net/ (if not, please consider doing so) 2. Will the presentation layer and the application layer be seperated? e.g. http://smarty.php.net/ 3. I'm going to assume you will be encoding all or a portion of the source code. What will you be using to do it with? (there are several choices for PHP, some commercial and some freeware) 4. How will the import of the existing FileMaker data into MySQL be handeled? That is, are you writing a tool to do it, or do we have to send our databases to you for conversion? Thats all for now. ;-)
1. Yes (written in-house). 2. Yes (written in-house). 3. Most likely Zend Encoder. 4. There will be a tool.
Oh, come on Mike, go ahead and ask...we're all dying to know anyway! Shawn, give us a few teasers anyway like 'possibly, if all goes well, but not guarenteed by the end of 2005' or something like that John
Since you wrote #1 in house, what database backends will it support? Is there a reason you chose to write your own rather than using the already-available ADODB library?
Hehe, yea, I know a lot of people are very interested. It would be nice to know if there will be a beta test period, and if that beta test will be open to the public or invite only.
By default the DB class is for MySQL. Out of the box MySQL will probably be the only "official" option, but parts of the system are not going to be encoded (for example the part that defines the database class). So if someone really wants to use something else, they will be able to by replacing that file. As far as why someone else's class mechanism wasn't used, is because it takes longer to go through their code to make sure it was written properly than it is to write it from scratch. Beta testing is going to be closed to the public (private).
Shawn, You may have already considered this, but just in case I am going to throw it out there. Could I suggest that certain tables NOT be encoded so that exiting custom tools can be more easily integrated? I am thinking at least the following tables: Core username and password Email alias and POP3 table Domains table Tech Support Table Usage Table I am sure over the years many ISP’s have built tools around their infrastructure and will not want to spend 2 years re-writing everything to fit into the new version. We have gotten a new DNS tool that sits between OG and our DNS servers where it authenticates against the OG interface, retrieves a list of domains with that account and then allows the customer to edit hosts for their domains. This was a 6-8 month custom in-house project because nothing else easily fit our needs and existing setup. It would really stink to have to do a total rewrite of this tool. Also, will there be better (easier to customize) marketing and sales analysis reporting? Just as a brain fart, why not contract Mike (under NDA) to speed this process along? Thanks Shawn!
My guess is that none of the SQL tables will be encoded -- there would be no point in doing so. The portion that will be encoded is the PHP code. As far as your custom app, the part that "talks" to OptiGold will likely need to be totally re-done. However, being able to get at the SQL data directly will open up a host of possibilities for add-ons to OptiGold, such as true DNS management, IP address management, etc etc. Shawn may already be adding such features as well, but he hasn't really stated what stuff might be included that isn't currently in the FileMaker based product..