You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.
The next release of CCP will be the version 6.0 (zuma) codebase which will require a re-write of the exisitng 5.1 (tiki) code to accomplish some of the architectural requirements that have been identified.
This is nothing new - the codebase has been re-written several times previously to prepare the program's architecture for broad functional enhancements.
We are targeting a launch in 2004 for version 6.0 (zuma). Right now the architecture is being planned, hence the poll question here. Once the scope of the release has been defined, we will be able to narrow down a more specific release schedule.
Concerning the poll: Do you have a preference as to the format in which the codebase is delivered, and if so, what is your preference?
This is a tough question for some users, and easy one for others, and some don't care as long as the program works. Each approach has it's benefits and weaknesses. I'll go over them here:
### Perl
Right now the codebase is written in Perl. Perl is an excellent language that is capable of just about anything. Perl's motto is 'there's more than one way to do it' and there is - dozens of ways, actually. The module repository at CPAN (cpan.perl.com) is full and provides tons of functionality and ideas to pull from. Thousands of modules that do anything you want are available and GNU licensed. It is a very robust language that has all of the necessary functions for a program like CCP. Additionally, webserver support is excellent and you can find a Perl hacker just about anywhere.
The downside to Perl seems to be it's future more than anything else. Right now the Perl5 codebase has stopped being developed (at version 5.8.0) and Perl6 is in the works. Perl6 should be ready for production within the next couple of years and will be an awesome scripting language. The problem is that Perl5 code will not run on Perl6 without translation (a complete re-write of CCP in Perl6 code). Initially webserver support for Perl6 will be limited and some of the CPAN modules used by CCP will not be available immediately. Windows support may be lacking as well.
Another downside to Perl is it's *apparent* lack of market share when compared to PHP. When looking at resources sites two years ago, Perl scripts numbered around 3,000 and PHP scripts numbered around 400. Now most resources sites show around 3,500 Perl scripts and 5,000 PHP scripts. There are two factors at work here: (1) PHP currently is a much more actively developed language, and (2) The PHP scripts available are generally one-off works that do small specific tasks - there are exceptions in the forum category, whereas the Perl scripts available are robust programs. Perl is still the de-facto language for e-commerce on the Net.
The Perl6 re-write probably will cause migration problems in the future. This *apparent* lack of market share may be affecting the marketability of programs written in Perl like CCP.
### PHP
I'm considering switching direction here and doing version 6.0 (zuma) in PHP. This consideration is being made more for the marketability of the program than any other reason. The Perl6 re-write does pose problems - but knowing the Perl community those problems should be minimal.
PHP is a good scripting language. It runs fast and lean and has support built into the core codebase for things like session management and database connectivity. These are items that are tackled in CCP right now using modules (session management written here, database connectivity is from the CPAN module DBI).
PHP also seems to be more popular than Perl right now. If the past two years are any indication, this trend should continue.
There is little doubt in my mind that a PHP version will run a bit faster than it's Perl counterpart. PHP has a small module repository called PEAR (pear.php.net) that has around 250 modules presently available. More modules come online every day, but it pales in comparisson to Perl's CPAN.
The version 6.0 (zuma) codebase will be doing many of the same things that 5.1 (tiki) does now. Database connectivity will be through a db wrapper (DBI is used right now). CSV file support will be maintained (DBD::AnyData and SQL::Statement are used now). Two key encryption will be used (HCE_MD5 is used now). Server to server communications will be supported (LWP and Net_SSLeay are used now).
The problem is that PHP doesn't have all of this stuff available in the core code or modules on PEAR right now. Some of it's there now:
Perl's DBI - There's a PHP module named DB that provides the same functionality - it is actually based on the Perl DBI. Support for MySQL, PostgreSQL and Microsoft SQL Server is available.
DBD::AnyData - There is no current PHP module that supports connectivity to CSV files via SQL. This would have to be written and contributed to PEAR. I suppose I'm the guy to do that. We definitely need CSV support.
SQL::Statement - There is a PHP module named SQL_Parser that looks to be a basis of what is needed to parse SQL statements for CSV use. It's based on the MySQL lexer and supports ANSI SQL. It is also directly derived from the Perl SQL::Statement module. It's got issues right now with not recognizing parens in WHERE statements - which is huge. This module needs some work to be CCP ready - or I would have to write and contribute my own SQL::Statement module.
HCE_MD5 - There is no HCE encryption module on PEAR, but there is an HMAC module that may work. More research is needed on this. If HCE is the way to go, that module will need to be written and contributed to PEAR.
LWP and Net_SSLeay - PEAR has a module available named HTTP_Request that supports this. This module needs to be tested extensively, especially for SSL. It does not use cURL, rather a direct connection to openssl, so support on Windows may be an issue. We may need to use cURL for SSL with PHP.
PHP does offer cool things like built-in session management and because it's a parser in nature, there would be no need for CGIGET and CGIVAR tags in the elements.
A re-write in PHP would take considerably longer (probably three months longer) because of the lack of availability of core components like built-in SSL support and relational CSV connectivity.
### CCP6
While reading this you are probably either saying - yes, go with PHP; no - don't go over to the dark side - stick with Perl; or don't care as long as it works. Please, just offer your opinion and any useful comments you may have - especially the reason for your decision.
A little bit about the next version...
CCP version 6.0 (zuma) will use a completely modular architecture. While 5.1 (tiki) is modular in nature, upgrades require full codebase changes. With 6.0 (zuma) we're going to move away from this and enable upgrades to modules specifically. This will allow for third party development of modules and completely administrator web-based methods of installing updates, new modules and upgrades. FTP access will not be necessary. Additionally, we should see speed increases in Perl as well as PHP (depends on our direction) as a result of this approach.
Additionally, 6.0 (zuma) will provide all functionality in just about every other e-commerce product available. This is a lofty goal - but attainable in a modular environment with proper research. Right now we are researching all available programs and compiling a list of features that need to be supported. There will be no need to look away from 6.0 (zuma) for a feature as everything that's available on the Net to date will be available.
###
Please consider these points and offer your feedback. As always, your comments are important and affect the product's future. Thank you.
Offline
Nick,
On another note, what are the pro's and con's to the end users as far as modifications, design changes, and over all which one, if any would be easier for the end user to make changes in Zuma?
I know for me, that Perl is more difficult to understand than PHP. I have been easily able to modify the design and layout of PHP scripts much easier than that of Perl. As for users custom coding special needs/features which from a technical and non-technical point of view would be easier for someone to do? We seems to have a strong user base who likes to tweak things, so would Perl or PHP be easier for exisiting and new customers to tweak?
Offline
I have no preference as to the scripting language to use--I have no experience in that. I'm fully confident that you will make the best choice and will come up with many improvements to a fine product.
What I'm not confident of is whether you will ever address the issue of how the average user is to implement the program. Perhaps you are directing your sales toward the programmer or more technical market. If so, you are missing the biggest part of the market, which is to the small, not so technical businesses.
I would encourage you to create a detailed user manual. Every feature should be explained with detailed instructions on how to implement that feature. Go into detail about how to blend the shopping cart into a website. This is what every user wants to do; very few serious businesses want to duplicate the default look of the cart.
I guess I represent the dufus side of your customer base. I've made over 200 posts and still don't know how to implement the program. However, there's a lot of us over here, so keep us in mind. You've got a great product.
Offline
Looking at this from a web hosts point of view, if I have two programs that do basicly the same thing and one is written in perl, the other in PHP, I would sooner have the PHP program due to the load that the perl script places on the server.
That said, I think that there are two distinct markets for your cart: Those who are diehard Perl fans and those that are diehard PHP fans. What are the possibilities of having a version of your cart in both languages?
Offline
From EagleWolf:
On another note, what are the pro's and con's to the end users as far as modifications, design changes, and over all which one, if any would be easier for the end user to make changes in Zuma?
I don't think it will matter either way. The codebase will be made up of functions (in PHP) or modules (in Perl) and from my experience the code looks the same - fairly complex - in each. Ease of editing in PHP is evident in smaller simple scripts that don't do much where much of the code is embedded in the HTML. We're seeing the same ease of editing in tiki right now with the CGIGET and CGIVAR tags.
From Altmedic:
I would encourage you to create a detailed user manual. Every feature should be explained with detailed instructions on how to implement that feature. Go into detail about how to blend the shopping cart into a website. This is what every user wants to do; very few serious businesses want to duplicate the default look of the cart.
The CCP6 codebase will include embedded instructions which will be extracted to POD (Perl) or PHPdoc (PHP) into an HTML based manual that details all functionality in the program. In addition, a users manual that will be at least twice as large as the current one is planned. Documentation issues for both regular users and developers will be addressed.
Additionally, wizard modules should be available to make the store administration simpler for the less savvy users.
From TerryA:
That said, I think that there are two distinct markets for your cart: Those who are diehard Perl fans and those that are diehard PHP fans. What are the possibilities of having a version of your cart in both languages?
From a support and maintenance standpoint, one version is the way to go. If writing two were a viable option, I don't think we'd be discussing it here. It's time to make a decision as to where the future of the codebase should go. As of right now, we have as many people who would like to see it coded in PHP as those who want to continue with a Perl codebase or don't care.
Offline
In working with CCP for the past 9 months and working with dozens of users doing modifications and site integration I feel one key issue that needs to be a main concern is the migration of the existing userbase. If PHP is used it will involve a greater task to upgrade from 5 to 6 as many web hosts don't offer the PHP on the existing account that the user may already be using. Also, many many people have had customization done to their installation that will not transfer smoothly to the newer version. Just upgrading from 5.0 to 5.1 has been a big issue with many users.
CCP is a fantastic product built for the web developer to create an ecommerce site. A decision has to be made to make the next version for the web developer or the business/site owner. Pain staking effort should be undertaken to develop the product with the site owner in mind. Most of the people that we work with on CCP projects really have no idea how to use most of the features and usually go about things in the most time consuming and difficult manner. They overlook so many of the features that would help them make their site do the things they need and look the way they want it to because the program is very complicated. To understand what CCP can do requires that you spend a tremendous amount of time to get familiar with all the features and test every part out. I am know for a fact that once you do it is the most powerful ecommerce product on the market. What we do for clients in minutes can take the typical CCP site owner days to accomplish if they ever do figure it out.
I would recommend making 6.0 a completely stand-alone product and not an upgrade of 5.1. IT will be a totally different product. 5.1 should be maintained so that all the businesses that are using it effectively will be supported. Only fixes should be done to the product when necessary.
There is no reason for a great deal of existing businesses to upgrade to the next version unless it is understand exactly how vital it would be to their business success. IF that would be the case then they should switch to a new installation of the new product instead of thinking it will be a simple upgrade.
Thanks for all your efforts and we are always here to help.
Steve Sunshine
Web Marketing Services
Offline
Tough tough question. Each has it upsides and downsides huh.
Well, sounds like a lot of work to switch to PHP and a little apprehension about the modules not currently supported and how Windows might have issuses, etc.
I'd say whatever works but that doesn't help I know. I'm all for whatever is going to work for everyone (windows, linux, etc.). And of course less server load, quicker running program.
It's scary that new Perl code isn't being released for YEARS (yikes) so with that I'd say you gotta stay with the latest and greatest (PHP) but then what happens when the new perl code DOES come out? Rewrite the code again ? ;-)
Since it all comes down to $ I think you need to ask which is going to bring more customers? Perl or PHP? Who are your customers - do they really know what Perl and PHP are? Do they care? I think we're looking for a program that does a lot (CCP does it all practically), user friendly and inexpensive. That's why I bought it.
Just my 2 cents for NOW ;-)
Why not send a mass email to us all and ask for some marketing type information.
Offline
Personally with a couple fo installations under my belt but no real desire or need to mess around under the hood, it really doesn't make any difference
I think from your standpoint keeping it in Perl makes more sense. It works, it's simple to install and if you add more functionality and follow through with your goal to make it *more* user friendly to customize within the admin itself, I would stick with Perl.
Pros -
runs on pretty much any server
modules exist to do what you need
going to be around a long time
works
I would follow a previous suggestion and make the product completely independant of v 5.1 with some easy data conversion tool if needed. I don't think you *have* to build on legacy code unless you feel it makes good business sense.
I appreciate the great product.
Best
Grant Simmons
Having just worked through getting a store online without an extensive knowledge of perl, it would not make much difference to me if it was perl or php. (both greek to me!)
My customers don't care - they just want it to work!
Bottomline -
1) PHP would be fine provided that some conversion tools are available to make the transition as painless as possible.
- Of course if support for the perl version is still available conversion then becomes a personal choice driven by the new features, etc.
2) Better documentation would be essential (both versions) - the "search until you find it in the code" method stinks.
I would also vote for the separate product suggestion.
Thanks for asking for my 2 cents.
Ed
Offline
I think changing to PHP might be better and it will make the cart much faster. I've been playing around with OS Commerce just for fun and it's just so much faster and has so much more scripts online you can dowload for it.
Petro
I want to add that I don't think Perl 5.8 is going to disappear anytime soon. As you have mentioned, CPAN is filled with all sorts of modules. Even with the introduction of Perl 6, I think Perl 5.8 has many years of life remaining. There are also a lot of Perl programmers around who are maintaining applications and they are not about to abandon Perl 5.8 for version 6. So I do think Click Cart Pro with its extensive underlying Perl code, could survive quite nicely as as Perl app for a few more years.
Now with that said, I think the reason for CCP to move to PHP shouldn't be because Perl 5.8 is getting old, but because PHP is a much better language to use for web applications than Perl. As several folks have pointed out, PHP is faster than Perl and I think it's easier to use. I have developed with both and I have found the PHP code structure to be very similar to Perl, and yet because PHP is actually coded on the web page itself, it is much easier to work with and troubleshoot. It would be easier to install. Unlike Perl, you don't have to worry about setting permissions. My hosting company doesn't allow telnet and SSH and I am limited to FTP, so recoding CCP to PHP would make my life much easier.
- - - Steve
I would like to see CCP moved to PHP for performance. I agree that developing a conversion method from 5.1 to 6 should not be a concern, besides... it gives me a reason to redesign my site.
I am just bummed that Tiki is not long for this world becuase I wanted to get some fancy-schmancy custom functionality done up.
I just beg that you guys keep the current admin navigation scheme or at least something close to it. I have done some work with X-Cart (PHP) and god almighty it's UI is abismal.
So when do we get to start piling on our feature requests for Zuma!?
Kiko
Offline
As posted by 'moneymancn' in the 5.1 support forum - sorry for the move - I'd like to keep these all in one spot:
Hi,
As a newbie and a small company with now an IT specialist I suppose so long as it works Ok I don not care too much about the the "engine"
We just upgraded and as has been said before its a great product and easy to use after a bit of practice.
We do not spend our time trying to hack or put on the latest mod etc -we spend our time marketing our site and looking after our customers.
So,any new edition should for us be by choice as was suggested before as a stand alone edition,so that those who wish to buy it for its "improved" engine can do so whilst leaving the rest of us who are still learning the current version(and by no way using it to its full capacity yet!!) can at least not be forced to digest yet another load of technical stuff in which we have little interest so long as it continues to do the superb job it is already doing.
We also need to be sure,please excuse my lack of knowledge perhaps,that we can host this with nearly any reputable hosting company without a bunch of problems.
User manuals need to be written by a non tech person please ans be of a step by step nature if possible.
Anyway,Nick and co.,please keep up the great work for a great product,we are delighted
Michael
Offline
Thanks to everyone for your input thus far. At this time I'd like to request more comments and reply on some issues raised:
From stevesunshine:
I feel one key issue that needs to be a main concern is the migration of the existing userbase. If PHP is used it will involve a greater task to upgrade from 5 to 6 as many web hosts don't offer the PHP on the existing account that the user may already be using.
Support for PHP today is practically as widespread as support for Perl. This suprised me when I reasearched it. According to Netcraft (wwwnetcraft.com) Apache webserver has a 67.43% market share as of 12/2003 and continues to increase. Apache webserver has had built in support for PHP for several years now. Microsoft server market share is decreasing slowly once again - a 20.87% share of the market. These statistics were found here:
And comprise a survey of 45,980,112 sites. Here is an excerpt from an article at Netcraft:
From Netcraft:
Although PHP is universally thought of as implying Linux, Apache and MySQL, nearly 7% of PHP sites [when counting by ip address] run on Windows. This has doubled over the last year, and on its current growth trajectory PHP will overtake Cold Fusion as the most popular non-Microsoft scripting language used on Windows during the next year.
The full article can be found at:
The figures in this article are what is most interesting: of 45,000 sites surveryed using Windows webservers, 35,000 (77%) support PHP. While I have no numbers on ActiveState Perl support on Windows, I expect Perl support on Windows to be very comparable.
The bottom line is that a move to PHP from Perl will not affect the installability of the program negatively. A comparative level of support is available for each. The minimum percentage of servers supporting PHP is 82% - that's Apache & Windows webservers only. This does not count all the other Unix servers that run Netscape or NCSA servers that support PHP.
Users who wish to migrate from Perl to PHP shouldn't have any trouble doing so on the same server account they're currently using.
From stevesunshine:
A decision has to be made to make the next version for the web developer or the business/site owner. Pain staking effort should be undertaken to develop the product with the site owner in mind.
Agreed. We talked about this before offline. Before addressing this further, I would like to discuss the planned architecture of CCP6 (whether it be in Perl or PHP):
From Kryptronic Internal CCP6 Architecture Doc:
The CCP6 (zuma) release will be architected based on the RedHat RPM schema. There will be a core codebase similar to a kernel that will make up the static component of the installation. The core codebase will consist of:
(1) scripts in the cgi-bin directory (one for site functions, one for admin functions)
(2) CCP modules sub-directory in the data directory for housing CCP modules
(3) CPAN/or/PEAR modules sub-directory in the data directory for housing public modules
(4) Various data components related to temporary files, elements and tables
(5) Various media components related to images and scripts
Included in the CCP component will be static components. The static components will house functionality to load dynamic modules at runtime from within the CCP and CPAN/or/PEAR repositories.
Modules required by the core codebase that must be installed initially will include:
(1) Administrator session management module(s)
(2) Administrator displays module(s)
(3) Module management module(s)
Bascially the core codebase will need to be capable of authenticating the Administrator, presenting a web-based admininistrator display and managing dynamic modules. Each of the modules and components listed above, if stored in the world-writable data directory, will have the ability to be upgraded dynamically as well.
With this core in place, it will be possible to update the codebase by upgrading and installing modules dynamically via the web-based administrator. Each module will need the following components:
(1) Install routine - This routine will provide the functions necessary to install the module. Items included in installation may be the creation of database tables, table columns creation of elements, addition of data to existing tables.
(2) Delete routine - This routine will provide the functions necessary to delete the module. This would include deletion of tables, table columns, table row additions and elements created during installation.
(3) Upgrade routine - This routine will be present in the initial release of each module, but will have no upgrade logic associated with it. With subsequent releases of modules, this upgrade routine will perform all legacy upgrade tasks rather than doing a full blown installation routine.
(4) Various task based routines - These routines will provide the actual functionality of the module.
(5) Documentation of all API calls (for developers) and administrator functions & logic (for everyone).
After installation of the core codebase, all modules should be upgradable to newer versions. In addition, modules must have the capability of being marked as non-upgradable by developers when custom changes are made to module code.
Certain modules will depend on the presence of and lowest compatible version of a module being already installed. This will be handled by the module management functions to ensure that the functions that specific modules require will be available. Because modules will be versioned, it will be necessary that the API of each is maintained in such a way that legacy support is provided.
There will be functions available within the web-based administrator to install, update and delete modules at will. The delete function will only be available for non-core modules. This means that an update to the codebase or the inclusion of a new feature or module will not require FTP/SSH based installation. The core administrator functions will provide a web-based interface to automatically download and install/update modules from Kryptronic servers.
Third party developers will need to contact Kryptronic and go through module certification to have their modules included in the codebase. By taking this approach to a fully modular architecture and delivery system, several things happen:
(1) After installation, all upgrades are web-based.
(2) If custom modifications have been made to modules, they can be excluded from upgrades.
(3) No knowledge of how to install scripts or use FTP/SSH will be needed to upgrade and/or update installations.
(4) Modules will be available on an as-needed basis.
Concerning point (4): Rather than delivering the program with 100% of the functionality with only 20% being used, a leaner, faster version is deployed which only has the functions the administrator needs or cares about. This leaves the installation small and clean. If a function is needed, it can be downloaded. If the user base requests a function, it can be coded into a module quickly and readied for download. If a small percentage of the user base wishes to use a particular function that wouldn't benefit the entire user base, a module could be created just for those users - without affecting anyone who doesn't install it.
The current codebases (5.1 - tiki being the latest) requires large releases which take a long time to get together and new installations which replace custom code modifications. Using the modular approach with web-based delivery, we eliminate these issues and can release new modules quickly one-by-one. Using this approach also makes beta testing a simpler task as only new modules and how they affect required modules will need to be tested before each release/update.
When reading the architecture doc quote, you can see that the core codebase will be very flexible. How user friendly the administrator and store are really depends on the modules used for those interfaces. THere will be at least two admin modules available: developer and owner. One will offer full control at a detailed level - the other will offer wizard based admin. If they're both loaded, you'll be able to switch interfaces dynamically. I also see things like one-click checkout modules and different types of discount modules, various shipping script modules, etc. being available.
From stevesunshine:
I would recommend making 6.0 a completely stand-alone product and not an upgrade of 5.1. IT will be a totally different product. 5.1 should be maintained so that all the businesses that are using it effectively will be supported. Only fixes should be done to the product when necessary.
It will be standalone, just as 5.0 was standalone from 4.0 and 5.1 was standalone from both, and all new releases going back to 3.1 were standalone from the previous releases. Up to and including the 6.0 install will require a new FTP/SSH based installation and the upgrade process will include a data import from the existing 4.0/5.0/5.1 install. This is nothing new. What will be new is that for upgrades past 6.0, we will be upgrading modules on an as-needed basis and for the future (as far as we can look into it, anyway) all upgrades will be web-based updates to and installations of modules directly within the production install.
There will be an upgrade available from 4.0/5.0/5.1 to 6.0 regardless of whether 6.0 is delivered in Perl or PHP. For support of the 5.0/5.1 codebase, that will continue as long as it's needed by the community. Once 6.0 is under development, feature enhancements (upgrades to higher 5.x versions) will not be available, however if there are any support issues, they will be addressed. If updates (fixes) are needed, they will be packaged and made available.
From stevesunshine:
There is no reason for a great deal of existing businesses to upgrade to the next version unless it is understand exactly how vital it would be to their business success. IF that would be the case then they should switch to a new installation of the new product instead of thinking it will be a simple upgrade.
That's always been the case. We have never offered an upgrade to get away from a buggy products. If the software has any issues, it is fixed with an update. If you want new features, you upgrade. 6.0 will make both processes simple.
From morvak:
Well, sounds like a lot of work to switch to PHP and a little apprehension about the modules not currently supported and how Windows might have issuses, etc.
The modules not being supported are my worry - not yours. If they don't exist and we need the function, I'll have to write them. For your Windows concerns, see above in my post here.
From morvak:
Since it all comes down to $ I think you need to ask which is going to bring more customers? Perl or PHP? Who are your customers - do they really know what Perl and PHP are? Do they care? I think we're looking for a program that does a lot (CCP does it all practically), user friendly and inexpensive. That's why I bought it.
It appears from the voting so far that users would prefer a PHP based solution or just don't care. Support for Perl is less than I thought it would have been. We will continue with the goal of making CCP user friendly and inexpensive no matter what is done with the next version.
From Grant Simmons:
I think from your standpoint keeping it in Perl makes more sense. It works, it's simple to install and if you add more functionality and follow through with your goal to make it *more* user friendly to customize within the admin itself, I would stick with Perl.
User friendliness will be a main goal no matter what. It's good to hear from a Perl die-hard
From webed:
I would also vote for the separate product suggestion.
Support will continue for the 5.0/5.1 codebase - no doubt. As far as releasing a new version in both languages - that won't be done. One or the other must be chosen.
From Guest_Petro:
I think changing to PHP might be better and it will make the cart much faster. I've been playing around with OS Commerce just for fun and it's just so much faster and has so much more scripts online you can dowload for it.
OS Commerce is a nice app, but has it's drawbacks. The main one is it's failure to support multiple databases. It only supports MySQL. Being that all the data is stored in MySQL, reason holds that that will make it faster when compared to a site storing data in CSVs. I've been doing some prototyping in PHP and have found that execution speed is a little better than in Perl because of server side processing. PHP is executed in the same process as the webserver is running - Perl runs in it's own process forked by the webserver. Because of the time involved in forking a new process and warming up the Perl interpereter on each page load, PHP seems to be faster (in my prototypes anyway).
From SteveTheHack:
Now with that said, I think the reason for CCP to move to PHP shouldn't be because Perl 5.8 is getting old, but because PHP is a much better language to use for web applications than Perl. As several folks have pointed out, PHP is faster than Perl and I think it's easier to use. I have developed with both and I have found the PHP code structure to be very similar to Perl, and yet because PHP is actually coded on the web page itself, it is much easier to work with and troubleshoot.
All true. I still plan to write the module delivery and registration servers for CCP6 in Perl as it's programming functions on the socket level are superior to PHP for accepting requests and forking daemons. The whole idea here is to ask the community what it wants and deliver it. Funny thing you said about PHP looking like Perl. My function and class prototypes and calls look so hauntingly like Perl it's scary.
From thekiko:
I am just bummed that Tiki is not long for this world becuase I wanted to get some fancy-schmancy custom functionality done up. I just beg that you guys keep the current admin navigation scheme or at least something close to it. I have done some work with X-Cart (PHP) and god almighty it's UI is abismal.
The release of zuma is a way off. Right now we're just trying to figure out what to write it in. Planning what you're going to do with your tiki version based on the release of zuma isn't the best policy. If enhancements to your tiki design are going to bring you in more money - do them. I think user friendliness has been addressed above to death...
From moneymancn:
User manuals need to be written by a non tech person please ans be of a step by step nature if possible.
Agreed on that point. I will make a note to have all module documentation reviewed by non-techies. Thanks for the comment.
From thekiko:
So when do we get to start piling on our feature requests for Zuma!?
LOL. Let's figure out how it will be written first, then I'll open up a forum section for it and everybody can post away as well as get status updates.
Offline
Just to post an update:
I have been continuing the prototyping of running zuma under PHP and with each line of code I write, I'm starting to like PHP more and more. The lack of modules available is going to create it's own set of headaches, but all in all PHP is a more solid language than I ever gave it credit for. It's got about 1/4 of the functionality of Perl, but that 1/4 seems to be all the stuff we need to run ecom on the web.
Also, on a side note, I've tested on both RedHat linux and Windows (thanks to Imaginary Planet for the Windows test account) and it appears we have all the functionality working on both OSes to fully automate the module delivery system.
It's been a productive week and I can say that a solution in PHP is viable if the community wants it that way.
Is that what everyone is asking for?
Offline
webmaster,12/06/2003 11:52:31 AM wrote:
Is that what everyone is asking for?
I crave it!
Kiko
Offline
Hi All
From a mac user point of view, PHP websites can be problematic for the end user (site visitor) we have been to many php enabled sites and every one has had an issue with the speed and reliability..Maybe it was a design fault, but the faults were too common, and they magically dissapeared when we visited the same sites with a PC..
Soemthing to look at maybe!!
One thing, it would be nice to see all the mods Nick has made for us on the new version.
Thanks Mark
Offline
[QUOTE]From a mac user point of view, PHP websites can be problematic for the end user (site visitor) we have been to many php enabled sites and every one has had an issue with the speed and reliability..Maybe it was a design fault, but the faults were too common, and they magically dissapeared when we visited the same sites with a PC..
[QUOTE]
We design and test all our websites on both platforms and our main language is PHP, and I would have to say I have never had any problems with PHP on a MAC. I not sure what problems you are having, but I haven't come across these issues with PHP.
I would love to see CCP developed based on PHP. It would make life so much easier for us, only because we are familar with the language and I would have to say that there are so many available add-ins that we could incorporate in a PHP based CCP. Speed wise it would make the cart alot faster and with all the available resources on PHP, I think the developers who want to modify the cart would find an easier time doing so.
From a mac user point of view, PHP websites can be problematic for the end user (site visitor) we have been to many php enabled sites and every one has had an issue with the speed and reliability..Maybe it was
I want to throw in my 2 cents on the so-called Mac/PHP compatibility problems here too. I have developed and worked on more than a dozen PHP applications, and we have never run into problems with Mac users. We test with all sites using
OS 9 and OS X, using most Mac browsers, including IE, Netscape, Mozilla, Safari and we have never had any problems with PHP.
Please post the links to the PHP sites that don't like Macs. I'd like to see them.
SteveTheHack
Since a wizard function will be available for webmasters, I was wondering if it were possible to intergrate a POP Authenticated e-mail question in the wizard as well ?
This way, users will no longer have to ask for extra sub routines or any implemental programming from other business.
Thanks.
Some issues to keep in mind with regard to PHP:
* Versionitis: how far back do you go with regard to supporting different versions of PHP? Will you start at 4.1.6, 4.3.2, or 5.0.0, etc? Can you ensure that the codebase will run equally well regardless of all the variations that can exist in php.ini?
* PEAR: The PEAR dependency chain seems more fragile than that exhibited by CPAN. Keeping module versions in synch can be a real headache. The eZ Publish folks have always written their own libraries and modules for their system. I've heard PEAR described here and there as a "coder's playground", not something you should rely on for production quality code. Writing your own libraries puts more of an onus on you to clearly document your architecture for anyone you partner with to provide customization services and support. The JavaDoc style comments you mentioned will certainly help with this. I shudder to think of having to maintain a custom set of low level libraries personally, especially when tried-and-true CPAN already works, but that's me.
* Programming idioms: I feel that the Perl "idioms" are more "mature" than those used in PHP. PHP coding styles vary widely from one programmer to the next, from straight procedural to pure OO in an MVC architecture, and everything in between. Combine this with programmers writing their own libraries for everything, and it begins to feel like "my PHP is not the same as your PHP". Perl may have "more than one way to do it", but I lately have not run into much code that makes good use of CPAN that looks like total greek. perl tends to look "familiar". This is coming from someone who has written a custom CMS in PHP, and worked with many different PHP applications.
Personally, my vote is to stick with perl. I messed around a bit with OS Commerce before I purchased Tiki, and I found OSC to be kludgey and buggy. I was surprised when I found eZ publish also exhibits some mysterious bugs that I could not find explanations for, in spite of the extensive logging and debugging facilities provided by ezp. I was so relieved when Tiki "just worked". If you can pull off the same using PHP, deal with the server variations, and document the architecture, I will be a happy customer, but I have been a little burned by PHP in the past. I'm also not convinced that using PHP will offer a huge performance advantage. I'm not willing to sacrifice reliability for performance. If you must use PHP, please test the snot out of it before you release. A reliable e-commerce codebase written in PHP would certainly be a big boost to the PHP community.
Offline
I was wondering if a live-update feature could be added in the new version ? So, for example, people who has problems with PayPal and needs additional database, all they would have to do is to use the live-update link and new sub routines could be added.
Offline
Nick,
As the polls seem to indicate, PHP could wellbe the best bet. I know our own site support forum relies on it (PHP).
The install was simple and straightforward. As for skinning it (Zuma) I guess the skinner community won't have to much trouble either.
That in mind, and all things being equal on your supprt side, (Webservers/Admin) issues and modules for Mac OS 9/10.x suport.
Let's go for it and see how what you can do.
I like the idea of keeping the load requirments lighter on the server processes.
IMHO - DO IT!
Nice to have you back!
Mark and Audrey Downing
Offline
I don't think performance is reason for choosing PHP over Perl. You can make Perl run just as fast and faster then the same thing in PHP. mod_perl can dramaticly improve perl code execution, and can extend the capabilities beyond what PHP offers. Perl has a lot of support out there via modules for caching content in many different ways to improve performance.
There are so many things relating to performance, and that affect performance that you need to know where the bottle neck is, and what the different options are to correct them. If the code is written to work under a mod_perl environment it wouldn't take much for an admin to enable mod_perl support and the site would literly jump out of the browser and hit you.
If a site owner is truely concerned with performance they are probably going to upgrade to faster servers to the point where they have the ability to control admin functions and the capability of enabling mod_perl anyway, so the simple solution to performance would seem to get a faster more dedicated box. From there you can enable mod_perl and rock the world even further.
I don't think that ease of HTML design work is a reason for choosing PHP over Perl. You can get the same capabilities from Perl with pieces of modules like HTML::Mason. With Mason's ability to parse HTML pages you can embed Perl in much the same way that you can with PHP. You don't have to use the entire HTML::Mason module, just the ability to parse the HTML for code.
I am planning customizations to CCP to fit my client's needs, and the support that CCP6 will have for such things will be great, but since its not coming out for a while I have to make all my customizations to CCP5.1 now and then migrate them to CCP6, and if I have to convert my Perl code to PHP it makes my job that much harder.
I want to add to CCP and make it work for my needs, but I would prefer doing that in Perl by far because I feel its a more solid language with more refined community support. It isn't behind the times, in fact its in a lot of ways more current then PHP. Just because its going to take a while for Perl6 to come out and they aren't doing development on Perl5.8 now doesn't mean that 5.8 isn't going to support anything that is coming in the next few years, it already support by far more then PHP has, and its still growing. We already know that Perl is going places with Perl6, and that Perl5.8 is competing on every ground that PHP is, and doesn't look like its stoping any time soon. PHP is just now catching up to some of the things Perl has been doing for years, and it still isn't as powerful. PHP5 is going to have better XML support, where Perl already has great XML support yesterday.
It seems people seems to want PHP for something easy, and people want Perl for something powerful.
I want something powerful if I am going to write something to extend the capabilities of CCP. I want something that I can easily add functionality with. I don't want to have to write some module for something that is already written in Perl, and has been around for years.
I'm not wanting CCP because its easy to use, I'm wanting it because it already has the code to do all the core functionality of an e-commerce package, and all I have to do is customize it. There are lots of easy to use Windows based e-commerce solutions out there, but I want something that I can customize, and add my own support to. Something that I can modify to meet the needs that I have. I want something powerful.
Offline
Thanks to everyone for their input thus far. I'm going to respond here to a number of posts above, then at the bottom of this post offer my position at the moment.
From djringtones:
From a mac user point of view, PHP websites can be problematic for the end user (site visitor) we have been to many php enabled sites and every one has had an issue with the speed and reliability..Maybe it was a design fault, but the faults were too common, and they magically dissapeared when we visited the same sites with a PC..
Your problems with Macs and PHP stem from bad use of HTML and CSS. As I am learning quickly, PHP is generally used by people who want to do things quickly for a specific platform rather than correctly for full platform compatibility. The code I've looked at recently sucks. An example is this forum - I can't view any posts in Netscape 4.0 (I was using it to test the new CCP site re-design). This is not the language's fault, rather the fault of the programmer and their inability to write HTML properly.
From Guest_scoutch:
Since a wizard function will be available for webmasters, I was wondering if it were possible to intergrate a POP Authenticated e-mail question in the wizard as well ?
The core administrator utility will have a function for managing all modules on the server. Their will either be a POP before SMTP authentication mail module available as a drop in replacement for the mail module delivered with the software, or the module delivered with the software will support it out of the box. Either way, it will be easy to replace x logic with y logic simply by installing a new module via the administrator.
From jasonw22:
* Versionitis: how far back do you go with regard to supporting different versions of PHP?
...
* PEAR: The PEAR dependency chain seems more fragile than that exhibited by CPAN.
...
* Programming idioms: I feel that the Perl "idioms" are more "mature" than those used in PHP.
...
Personally, my vote is to stick with perl. I messed around a bit with OS Commerce before I purchased Tiki, and I found OSC to be kludgey and buggy.
That's the thing. PHP is in it's infancy compared to Perl. According to the language's author, it wasn't meant to be a language at all - just a parser to do simple stuff. All support for language-type functions that you would expect to be part of the core have been hacked in by Zend.
PHP appears at this point to be lacking several major functions that are needed:
CSV file support and an SQL parser
A convenient way to handle virtual SSL connections (cURL seems to be the solution for everything)
A way to share variables globally (easilly) between different files
Concerning PEAR, the modules I've used have been good - but not good enough. For example, the SQL_Parser that's available doesn't account for parens in WHERE statements. That's such a basic feature in SQL. In order to use that module for CSV file support, it will have to be re-written. The module's author has been unresponsive in addressing the issue thus far. I have used the Archive_Tar module with sucess, though. I guess it's hit or miss. If zuma is done in PHP most if not all modules used will be based on PEAR modules but written by me.
The biggest and most blatent problem right now is PHP's inability to 'share variables globally (easilly) between different files'. I know this doesn't make much sense to most people, but if a variable is declared in one module, it's not available to another module (in a different file). Most PHP programs create and destroy database connections on a per-file basis creating tons of overhead because there's no apparent way to maintain the state of a connection from file-to-file or module-to-module. I haven't tried a full on OO approach to this as a solution yet - but in theory that could work.
The PHP code I've got running right now is ugly. It doesn't read well like Perl. It looks a little like Perl and to the regular HTML coder who wants to hack a bit, it isn't going to make much sense and break easilly. Here's an example:
// +-- // | Figure out which OS we're running so we know what to do with // | the slashes in the server paths we work with. If we are running // | a Windows OS, replace the / characters in the path with \. // +-- if (substr(PHP_OS, 0, 3) == 'WIN') { $global['os'] = 'Windows'; $global['pathchar'] = '\\'; $global['path_data'] = str_replace("/",$global['pathchar'],$global['path_data']); $global['path_media'] = str_replace("/",$global['pathchar'],$global['path_media']); } else { $global['os'] = 'Unix'; $global['pathchar'] = '/'; }
All this is doing is checking the PHP_OS constant, which I just found out isn't available on every install, and changes paths for includes to use \ instead of /. Because the Windows version of PHP requires the use of \, every file path in the entire program is going to need to be changed and will look like this:
$file = $global['path_data'] . "pear" . $global['pathchar'] . $filename;
Instead of the same thing in Perl:
$file = "$path_data/pear/$filename";
Talk about a convoluted mess. Because global variables are only global in the context of a file, the $global[] array is going to have to be passed on through each module & subroutine call. This may be averted with an OO approach, but then you're talking about some even sloppier looking code.
More on this below.
From scoutch:
I was wondering if a live-update feature could be added in the new version ? So, for example, people who has problems with PayPal and needs additional database, all they would have to do is to use the live-update link and new sub routines could be added.
Yes - that's the whole point of the module interface in the administrator. When a new feature or fix is released, everyone will be alerted via admin and will be able to install right from your admin interface.
From kingdavidK:
As the polls seem to indicate, PHP could wellbe the best bet. I know our own site support forum relies on it (PHP).
It seems like PHP is supported by those who *don't know* or those who want speed. Programmers are leaning towards Perl because it's mature and stable.
From m j:
I don't think performance is reason for choosing PHP over Perl. You can make Perl run just as fast and faster then the same thing in PHP. mod_perl can dramaticly improve perl code execution, and can extend the capabilities beyond what PHP offers. Perl has a lot of support out there via modules for caching content in many different ways to improve performance.
...
I don't think that ease of HTML design work is a reason for choosing PHP over Perl. You can get the same capabilities from Perl with pieces of modules like HTML::Mason. With Mason's ability to parse HTML pages you can embed Perl in much the same way that you can with PHP. You don't have to use the entire HTML::Mason module, just the ability to parse the HTML for code.
...
It seems people seems to want PHP for something easy, and people want Perl for something powerful.
...
I'm not wanting CCP because its easy to use, I'm wanting it because it already has the code to do all the core functionality of an e-commerce package, and all I have to do is customize it.
Agreed whole heartedly. My further comments (in the next post).
Offline