 | | |
| | |
|
Dave
Staff
/ Moderator
Sep 11, 2003, 1:20 PM
Post #2 of 13
(7219 views)
Shortcut
|
That almost sounds like a fortune cookie! : ) I'm not really sure what features you're asking for...
As far as SQL support, it's high on our list. But PHP isn't something we're going to pursue. We get requests from programmers to write our applications in PHP, ASP, JSP, Python, etc, etc. The thinking is apparently that then they could hack and extend the code.
However, this misses the point of our software. Our software is designed so you don't have to be a programmer to extend it, to add fields, to customize the templates, etc. We're going for the balance of flexibility and ease of use. We hope to make it even more flexible in future, but we're only going to do it in ways that make it open to non-programmers as well as programmers.
As far as people trying to clone our software, we know that happens, and it's been happening for a long time (over 4 years). The fact that we're still here tells you something about how people think our software and company compare. It takes lots of time and experience to make really good software. Believe me, if we could do it faster we would. : )
One thing you might be interested in, though, is the next version of Artman to be released (which just finished public beta) will have SSI parsing in dynamic pages. Meaning you'll be able to use standard SSI includes to load PHP headers or content (even from pages generated with search.cgi).
Dave Edis - Senior Developer
interactivetools.com
|
|
| |
|
woodwater
User
Sep 11, 2003, 1:47 PM
Post #3 of 13
(7210 views)
Shortcut
|
SiteWorksPro coming version 6, after Christmas.
vBulletin CMS, after VB3
Nephp, already out with ver 4.5
And many more others.
All in PHP and MySql.
You can do a survey with most webmasters on popular webmaster forums and ask which they prefer; Perl or PHP. Ask what they love and what they detest.
Anyway, it's your product. I really like your features and hope you guys will carry on the good work into PHP and MySql. However, it seems to me that your company prefer to stick to Perl.
It does not benefit me at all to continue preaching the changing competition landscape of your product to your company. Time will tell. Give it at most 1 year. The advantages accrued in the old paradigm will be outdated in the new.
|
|
| |
|
Dave
Staff
/ Moderator
Sep 11, 2003, 2:39 PM
Post #4 of 13
(7192 views)
Shortcut
|
I guess I just don't understand what relevance PHP (or any programming language) is. We don't have any Perl programmers using our software because it's Perl. For all intents and purposes you might as well pretend our software is compiled. The way we make our applications the language underneath is irrelevant.
I'm really trying to understand here. What if our software was compiled as an executable and didn't use Perl at all? How would you feel about that?
What about vendors who write apps in PHP and use Zend Encoder? Would that be better than Perl?
Is it that you want us to sell a "programming platform" based on a popular language that other programmers can build upon to modify or extend the application?
Even though they may seem similar, the products that focus on PHP to do everything serve a different market. They're for PHP Programmers and hackers. We're aiming for a more general market. Just like if we used Perl code in the templates you may not be able to use it, if we use PHP we cut out everyone who doesn't know PHP. We'd rather support all the PHP people, all the Perl people, and everybody else all at the same time.
Dave Edis - Senior Developer
interactivetools.com
|
|
| |
|
gfuchs
User
Sep 12, 2003, 1:40 PM
Post #5 of 13
(7117 views)
Shortcut
|
With products that build pages on the fly such as Vbulletin and other forum packages, the language and use of a database vs flat files makes an enormous resource usage difference in a heavily used site.
I used a perl/flatfile forum package in the past, and it became a resource hog after a certain usage point. In fact I was forced to a dedicated server to buy time to convert to a php/MySql package.
However this has no bearing with AM.
Since it builds static pages the actual use of the scripts is very low.
I have to admit based on the problems in the past I thought twice about a perl based product for content management. But after researching AM and realizing how it works I came to the same conclusion that I couldn't care less what it is written in as long as it works.
And I have absolutely no desire to change the code. I shouldn’t have to make changes to a product to get the features I need, and then have to re-apply the changes every time for a new release.
What I wanted was a professionally written and maintained product, not something written in someone's spare time.
It's all about determing your needs and finding the product to match.
AM met my requirements and I am happy with the results.
(I would like to see sub-categories added the product though)
Greg
(This post was edited by gfuchs on Sep 12, 2003, 1:48 PM)
|
|
| |
|
jcocking
User
Sep 12, 2003, 2:49 PM
Post #6 of 13
(7105 views)
Shortcut
|
Totally agree with Dave. Who cares what language it is written in. If it is a stable product that meets your needs, buy it. If it does not meet your needs then do not buy it. The language a software product was developed in has nothing to do with the key areas software is evaluated: features, functions, support and cost.
The reason content management systems were developed is for the ability to manage content. Once I had AM up and running, I do not have to touch the system. I now spend my time managing content. My readership does not care what it is coded in. They want content.
From a marketing perspective IA is providing a product that will run on 95% of all hosting environments. PHP with mySql is mainly the domain of Linux hosting environments. This accounts for 50% to 60% of the hosting environments. I think IA is pretty smart for building the system in perl/flat files that will run on every major shared/virtual/dedicated hosting solution today.
From a technical reason, and the reasons I purchased AM, was for its low impact to the server. AM is a publishing CMS tool (similiar to BroadVision). The system is built to publish static webpages. Webservers are great at delivering static pages. The speed of AM based websites is fantastic. The data base driven content management systems sound sexy, but become server intensive under any load. (This is why all the major Content Management Systems include a cache management tool to overcome this problem.) My site supports a visitor base of 600 to 700 visitors viewing 4000 pages a day on a shared hosting plan for under $10 a month. I do not think I could come close with dynamic(php/mysql) cms system.
If Dave and the IA crew want to rewrite AM in Pascal, I could care less. Keep up the awesome support and provide a bullet proof product and I will keep recommending it to people to install.
jeff
Jeff Cocking
Lotus Elan (AM 1.38)
VoIP Phone Comparisons (AM 2.02)
|
|
| |
|
void
User
Sep 15, 2003, 6:26 AM
Post #8 of 13
(7044 views)
Shortcut
|
Hi Woodwater,
I agree with you and the message in your headline :) Perl systems is not what people in general are looking for. I know I dont. My forum is php/mysql based, so's my link system and I would really prefer to have the same tecnically framework for the articles also. I gives me less to worry about. Less to learn. Its that simple. Theres nothing to discuss. Its all about preferences, and that why you wont get these guys to go your way. Because they prefer perl! And thats about it.
Now, I I'll change to the first well-equipped and well-supported php article system that comes along. Your links look promissing. Lets hope this evo-thing gains momentum. God knows not a day passes where I dont go looking for an alternative.
Cheers,
Tim
(This post was edited by void on Sep 15, 2003, 6:31 AM)
|
|
| |
|
Dave
Staff
/ Moderator
Sep 15, 2003, 12:04 PM
Post #9 of 13
(7018 views)
Shortcut
|
Ouch! :(
For the record, our main concern is what's the best for majority for our users, not what's best for PHP programmers or Perl programmers or any other group.
This doesn't mean we don't want to support PHP fans. We absolutely want to, but we want to find a way to do it that doesn't exclude ASP fans, JSP fans, and regular (non-programmer) web developers who just want to get something done quickly without having to be programmers.
A few months ago there was a thread called "PHP Article Manager" where a number of people sounded in (including Void and Woodwater). We proposed some solutions that would allow PHP programmers to integrate PHP scripts WITH the Perl CGI scripts and committed to making those changes. That thread is here: http://www.interactivetools.com/iforum/P11763-2/
We released a beta a month ago here:
http://www.interactivetools.com/iforum/P15855/
Despite the requests for PHP support in the forums, this beta had the lowest community support ever. Almost no one downloaded the beta, and no one at all sent us any feedback on it at all. Zero. Nothing.
Despite the lack of community interest, we've put in the work coding this and we plan to release it in the next week anyway.
If you guys are willing to take the time to tell us to rewrite our entire product in a different language that suits you, why don't you spend some time and help find solutions that will support not just PHP programmers but our other users too?
Dave Edis - Senior Developer
interactivetools.com
(This post was edited by Dave on Sep 15, 2003, 12:50 PM)
|
|
| |
|
dcalisaya
User
Sep 15, 2003, 12:59 PM
Post #10 of 13
(7005 views)
Shortcut
|
Well, I can say that Article Manager works in the purpose that have been created. Some sites have forums, comments, etc... but I think that it is not the end of article manager.
At the moment We use Artman in one of the site that have daily more than a million users. Why we even remain with Artman?
1. Sites with many visits generates queries in database MySQL and it goes up the load of the server, especially if it is a shared server.
2. With Artman we can configure to save indifferent kind of files: *. php, *. shtml *. html, *.. phtml, *. asp... etc.
3. If we save flat files in .php, we can personalize it, includes pages, queries to the database, etc, etc..
4. The design of artman is comfortable, easy to use for people that don't know anything about programming...
* 5. I would like that Artman data could be fine in MySQL. For that? simply MySQL manages the data well, it would also allow to take out data in some other pages, although the syndicate works very well.
Cheers
-----------------
Daniel Calisaya
Support Services http://www.mercadocristiano.com
"Imagination is more important than knowledge" <Albert Einstein>
|
|
| |
| | |
|
void
User
Sep 16, 2003, 3:07 AM
Post #12 of 13
(6940 views)
Shortcut
|
Hi Dave,
My post was not meant as a critique of the Interactivetools way. I was a simply calling attention to the fact that our preferences guides the choices we want to make. I fully understand that Perl guys want to make Perl solutions. At the same time I realize that what I really want is a php system to go with my other php systems as would a lot of people. Its simple a matter of what makes us comfortable.
I'm running version 1.29 and dont plan to upgrade anytime soon. Right now my site is stable and very busy, so I've decided not to rock the boat with betas or new versions unless they are marked as necessary. Instead, I focus my attention to bring all components within the same technical framework (php or asp.net - mysql) because this is where I feel at home.
All of this has nothing to do with the quality of Interactivetools products or services. They are both great. Its just not all that I need - but I see no point in bugging you guys with php anymore - or for that matter listen to technical counter arguments that misunderstands what goes on in php users heads. So I've gone looking for what I need. To find it?, well, thats another issue 
(This post was edited by void on Sep 16, 2003, 3:14 AM)
|
|
| |
|
Theo
Project Manager
/ Moderator
Sep 16, 2003, 3:00 PM
Post #13 of 13
(6898 views)
Shortcut
|
Thanks for contributing to this thread.
Since it's more related to PHP advocacy than to any specific Article Manager requirements, I've locked it and moved it to off-topic conversations.
Theo Wiersma
Project Manager
(This post was edited by Theo on Sep 16, 2003, 3:00 PM)
|
|
| |
|
Redesign Article Manager with PHP