Forums
This topic is locked
PHP development for MX - the response of InterAKT
Posted 06 May 2002 15:29:14
1
has voted
06 May 2002 15:29:14 Interakt Online posted:
Hello,There were a lot of discussions on the vision on PHP development in Macromedia MX.
People (uasers and extension developers) were complaining on the confusion that reigns over the PHP development choices. We are (along with Macromedia) in the "guilty" section.
We have released too many server models, ideed. And if for the UD4 version we'll leave it "as is" (it's too late to do something useful), for the MX version we'll release only one, powerful server model, along with Macromedia's original one: PHAkt2. PHAkt2 will be the core for all our extensions (ImpAKT will become a suite of server behaviors, NeXTensio will also work on PHAkt2).
We will also release two powerful migration engines, from PHAkt 1.3 to PHAkt2 and from PHP_MySQL to PHAkt2. If you have behaved nicely with the code (by avoiding manual code modification), you will be able to migrate your existing sites to the latest PHAkt version.
I will also comment another disturbing trend we have detected on this lists. Tim Green, once our strongest ally, now wants to remove us from the market, releasing it's own server model. (on the udzone PHP talkzone you will find more details)
We are very sad we have come to this.
Tim Green tryes to reinvent the whell by proposing the "holy grail server model" - by making the current PHP_MySQL server model supporting multiple databases. As we are the only extension developer that created a server model(until now), we can tell that this can't be done. There are references to mysql_* all over the place, and overloading native PHP functions with the same parameters is not possible in the current PHP implementation (as far as we have researched this). So it's utopian to think that the PHP_MySQL server model can be transformed into an database independent server model. Another server model has to be created for this to work.
I think there's no need to split the community in 3. We agree we were undecided to create PHAkt2, but MM is helping us and we are actively working on finalizing it - free. Tim's reasons for it's server model are not very convincing to us, as we are willing to correct most of our past mistakes.
We've lost Tim green as a partner and he has transformed into an enemy because we have proposed him to continue the work on his extensions (he announced on udzone, *without* telling us first, that he will drop the support for PHAkt/ImpAKT). We don't understand him at all. We might have been wrong, by not supporting our extension developers, but we are young and we admit we were wrong and we want to improve ourselves. You don't have to kill us and to re-invent PHAkt for that.
Tim also use a lot of nice words like ":GPL", "free", "database independence". We already have this in PHAkt2. It's free to use, free to redistribute and free to modify. The LGPL license is less restrictive on the "free" side, because it allows commercial updates to be released and the code doesn't have to be reported to the original developer. We also have database independence with ADODB, and Tim Green is trying to do the same way with it's PHPMXDB server model.
I must admit I'm shoked by his virulent response. He has already started with accusations on us, but I don't recall doing anything wrong with PHAkt (we are a small company and we have thought of abandoning developing PHAKt not long time ago, *from financial reasons*, but as PHAkt is free, this would not disallow other people to continue our work. However, our reasons were Macromedia related (they were ignoring us), and we have finally reached to understand each other)).
To deny some of Tim's accusations:
- PHAkt2 is free
- PHAkt2 uses Limited Recordsets. We have implemented our own version of Paged Recordsets and ADODB recognized that Cached Recordsets are not very useful, so we have choosed to ignore them.
- PHAkt2 will be much stabler than the previous versions.
- PHAkt2 will support it's extension developers much better.
- PHAkt2 will allow migration from PHAkt1 and from PHP_MySQL
- PHAkt2 will allow easy migration to our commercial products (and as many of you can confirm, it's nothing wrong in providing more powerful solutions commercially, as we are making a living from extension development).
- PHAKT2 IS ALREADY IMPLEMENTED! and Macromedia is testing it right now for a release along with the MX final release.
I think I have presented our opinion clear enough.
We have understand that we were wrong in some points, and we will offer a much greater support to our extension developers, because we have fallen in the same trap MM did : ignored the people that write extensions for our server model(s).
I alo suggest Extension developers to create their extensions for PHP_MySQL or for PHAkt2, as we'll provide them the tools to migrate between the server models. I use this opportunity to announce and release the "B Independent" migration program, that will convert all existing PHP_MySQL extensions for PHAkt2/ADODB, and viceversa.
Even if this is only an idea right now (I was overwhelmed with bad news today and I am also in a holliday today<img src=../images/dmxzone/forum/icon_smile.gif border=0 align=middle>, this program will assure extensions developers a clear path of migration from PHP_MySQL to PHP_ADODB (PHAkt2 server model name).
To conclude:
- PHAkt2 - the only server model we'll release
- ImpAKT2, NeXTensio2 - only new server behaviors based on tNG.
- "B independent" - migration program to/from PHAkt2 for extension developers (by InterAKT or with automated tools, we will investigate the right way)
- PHAkt1->PHAkt2, PHP_MySQL->PHAKT2 migration engines.
I will leave the office now, I will respond on this thread tomorrow morning. Let's hope we'll reach a consent that will please the users, the extension developers and us.
Alexandru
--
-----------------------
Alexandru COSTIN
Product Manager
www.interakt.ro/
+401 411 2610
Replies
Replied 06 May 2002 15:49:46
06 May 2002 15:49:46 Waldo Smeets replied:
Alexandru,
I like you very much and you have developed great products, but I really think that you are missing the point regarding some (most personal) issues. I'm not going to discuss them here, it's best to do so offlist. You know how to contact me.
Waldo Smeets -- www.UDzone.com Co-Founder
------------------------------------------
UDzone.com: The site for Macromedia
Dreamweaver UltraDev Developers!
I like you very much and you have developed great products, but I really think that you are missing the point regarding some (most personal) issues. I'm not going to discuss them here, it's best to do so offlist. You know how to contact me.
Waldo Smeets -- www.UDzone.com Co-Founder
------------------------------------------
UDzone.com: The site for Macromedia
Dreamweaver UltraDev Developers!
Replied 06 May 2002 17:02:58
06 May 2002 17:02:58 Tim Green replied:
Alexandru,
> I will also comment another disturbing trend we have detected on this > lists. Tim Green, once our strongest ally, now wants to remove us from > the market, releasing it's own server model. (on the udzone PHP
> talkzone you will find more details)
Unfortunately, it is clear that you have misunderstood my posts, and the clarifications that I have made to those posts in the same threads. I am not seeking to create a new PHP Server Model here. That would be preposterous, and would nullify all the comments that I have previously made regarding multiple PHP Server Models.
> Tim Green tryes to reinvent the whell by proposing the "holy grail
> server model" - by making the current PHP_MySQL server model
> supporting multiple databases. As we are the only extension developer > that created a server model(until now), we can tell that this can't be
> done. There are references to mysql_* all over the place, and
> overloading native PHP functions with the same parameters is not
> possible in the current PHP implementation (as far as we have
> researched this). So it's utopian to think that the PHP_MySQL server
> model can be transformed into an database independent server model.
> Another server model has to be created for this to work.
I don't believe that this is a "Holy Grail Server Model" at all. I just wish to fill in the gaps by developing more tools. These will ultimately benefit the developer. Isn't this the whole point of extension development in the first place?
I am also not seeking to "overload native PHP functions", whatever that is supposed to mean. As I've stated previously this will be done with additional behaviors. It is therefore not Utopian as the whole point of the extensibility layer is to allow developers to build on it, and provide enhanced functionality to everyone. In this respect another Server Model does NOT need to be created at all as we are only talking about Server Behaviors here.
> I think there's no need to split the community in 3. We agree we were > undecided to create PHAkt2, but MM is helping us and we are actively
> working on finalizing it - free. Tim's reasons for it's server model
> are not very convincing to us, as we are willing to correct most of
> our past mistakes.
Again, I am not building another Server Model. I do not know how I can convince you further, that to release additional PHP Server Models, will only split the PHP Community by the same amount. Extension developers need to know where they stand, and they do with ASP,ASP.NET,JSP and CFML. Unfortunately the overwhelming options for PHP are already dividing the community, and you seem to completely forget about the newbie developer. At this time we should not be looking at a Divide and Conquer strategy, because here, division breeds uncertainty, uncertainty breeds mistrust, and any newbie PHP Developers will just vote with their feet, and go and use a different development environment.
> We've lost Tim green as a partner and he has transformed into an enemy > because we have proposed him to continue the work on his extensions
> (he announced on udzone, *without* telling us first, that he will drop > the support for PHAkt/ImpAKT).
> We don't understand him at all. We might have been wrong, by not
> supporting our extension developers, but we are young
> and we admit we were wrong and we want to improve ourselves. You don't > have to kill us and to re-invent PHAkt for that.
Is it the responsibility of the developer to inform the manufacturer of his tool that he will no longer use it? No.
I made my announcement public when I felt that I had no choice, and had received no support and or consultation. I don't think that in this respect Interakt have any such right in complaining about my actions.
Isn't this exactly what Interakt did 2 weeks ago? When they were informing select PHP Developers and Macromedia representatives that they were no longer going to support UltraDev or DWMX, because they felt they had received no support?
My main gripe was that four minutes after receiving an email with proposals for me to 'hand over' development of my extensions to Interakt, that Interakt were also making public announcements, that they would be re-engineering my work. Of course all of this was done before I had a chance to respond, and it could be argued that Interakt were trying to buy public support by name dropping.
The notion that I am trying to 'kill' you, is completely unfounded. That would indicate that there is some form of malice at work here. Yet quickly it is forgotten, that thanks to myself and other PHP Extension Developers, Interakt now have the product stable that they do. I was supporting PHAkT, long before there were any commercial offerings from Interakt, and continued to support them publicly and privately, though I did not receive the same in return.
> I must admit I'm shoked by his virulent response. He has already
> started with accusations on us, but I don't recall doing anything
> wrong with PHAkt (we are a small company and we have thought of
> abandoning developing PHAKt not long time ago, *from financial
> reasons*, but as PHAkt is free, this would not disallow other people
> to continue our work. However, our reasons were Macromedia related
> (they were ignoring us), and we have finally reached to understand
> each other)).
Alexandru. I have made no accusations. I have only quoted you. My virulent response was to your public (and private) proposal for 3rd party developers to 'hand over' to you previously release 'free' extensions and to integrate them into your COMMERCIAl model. This implies profiteering, and in my opinion is unethical and unprofessional considering you have engineered the situation that we are currently in.
> To deny some of Tim's accusations:
> - PHAkt2 is free
I have never, ever said that PHAkT is not free.
> - PHAkt2 uses Limited Recordsets. We have implemented our own version > of Paged Recordsets and ADODB recognized that Cached Recordsets are
> not very useful, so we have choosed to ignore them.
Except you have used them in QuB, so they do indeed have a use.
> - PHAkt2 will be much stabler than the previous versions.
I cannot comment on this.
> - PHAkt2 will support it's extension developers much better.
How do you propose to support it's extension developers better? At the moment we have received zero support from you at all. So anything would be better. Are you prepared to go on the record, and publicly commit to ensuring that 3rd party extensions will not break in future releases of PHAkT 2?
If you cannot do that. Will you publicly commit to informing developers in advance of release whether an extension will be broken in an upcoming release, and explain why?
Will you commit to retaining all Macromedia-established naming conventions and workflow methods so as to avoid the UD4/PHAkT Recordset.htm/RecordsetPHP.htm debacle, that consistently broke behaviors?
> - PHAkt2 will allow migration from PHAkt1 and from PHP_MySQL
This is an excellent idea, and I wholeheartedly support the use of migration engines of this type.
> - PHAkt2 will allow easy migration to our commercial products (and as > many of you can confirm, it's nothing wrong in providing more powerful
> solutions commercially, as we are making a living from extension
> development).
Absolutely. There is nothing wrong with this at all, providing that you are not trying to use your popularity to increase the product stable of your commercial offerings by devouring previously available free works.
> - PHAKT2 IS ALREADY IMPLEMENTED! and Macromedia is testing it right
> now for a release along with the MX final release.
Congratulations. I wish you every success.
> I alo suggest Extension developers to create their extensions for
> PHP_MySQL or for PHAkt2, as we'll provide them the tools to migrate
> between the server models. I use this opportunity to announce and
> release the "B Independent" migration > program, that will convert all > existing PHP_MySQL extensions for PHAkt2/ADODB, and viceversa.
This is an interesting proposal. One which I am sure will benefit many extension developers. One question regarding this, though. Considering the nature of many available extensions, this is a tall order. Who would be responsible for the support of converted extensions? If some form of migration system is implemented, how can support be guaranteed for such extensions when there is considerable difference between the two systems? Wouldn't this ultimately mean that the extension developer would have to learn both systems, and ultimately develop for them both, in order to guarantee their support levels?
I look forward to hearing your proposals.
All the best
Tim Green
Develop real purchasing power for your website with IntelliCART,
the PHP Shopping Cart Management System for UltraDev 4.
Tim Green
Extension & PHP TalkZone Manager
<font size=1>-------------------------------------------
<i>Please read the Forum FAQ before posting
a question to this TalkZone.</i>
-------------------------------------------
www.UDzone.com : A dynamic Dreamweaver,
Ultradev and Fireworks site for developers
by developers.
-------------------------------------------</font id=size1>
> I will also comment another disturbing trend we have detected on this > lists. Tim Green, once our strongest ally, now wants to remove us from > the market, releasing it's own server model. (on the udzone PHP
> talkzone you will find more details)
Unfortunately, it is clear that you have misunderstood my posts, and the clarifications that I have made to those posts in the same threads. I am not seeking to create a new PHP Server Model here. That would be preposterous, and would nullify all the comments that I have previously made regarding multiple PHP Server Models.
> Tim Green tryes to reinvent the whell by proposing the "holy grail
> server model" - by making the current PHP_MySQL server model
> supporting multiple databases. As we are the only extension developer > that created a server model(until now), we can tell that this can't be
> done. There are references to mysql_* all over the place, and
> overloading native PHP functions with the same parameters is not
> possible in the current PHP implementation (as far as we have
> researched this). So it's utopian to think that the PHP_MySQL server
> model can be transformed into an database independent server model.
> Another server model has to be created for this to work.
I don't believe that this is a "Holy Grail Server Model" at all. I just wish to fill in the gaps by developing more tools. These will ultimately benefit the developer. Isn't this the whole point of extension development in the first place?
I am also not seeking to "overload native PHP functions", whatever that is supposed to mean. As I've stated previously this will be done with additional behaviors. It is therefore not Utopian as the whole point of the extensibility layer is to allow developers to build on it, and provide enhanced functionality to everyone. In this respect another Server Model does NOT need to be created at all as we are only talking about Server Behaviors here.
> I think there's no need to split the community in 3. We agree we were > undecided to create PHAkt2, but MM is helping us and we are actively
> working on finalizing it - free. Tim's reasons for it's server model
> are not very convincing to us, as we are willing to correct most of
> our past mistakes.
Again, I am not building another Server Model. I do not know how I can convince you further, that to release additional PHP Server Models, will only split the PHP Community by the same amount. Extension developers need to know where they stand, and they do with ASP,ASP.NET,JSP and CFML. Unfortunately the overwhelming options for PHP are already dividing the community, and you seem to completely forget about the newbie developer. At this time we should not be looking at a Divide and Conquer strategy, because here, division breeds uncertainty, uncertainty breeds mistrust, and any newbie PHP Developers will just vote with their feet, and go and use a different development environment.
> We've lost Tim green as a partner and he has transformed into an enemy > because we have proposed him to continue the work on his extensions
> (he announced on udzone, *without* telling us first, that he will drop > the support for PHAkt/ImpAKT).
> We don't understand him at all. We might have been wrong, by not
> supporting our extension developers, but we are young
> and we admit we were wrong and we want to improve ourselves. You don't > have to kill us and to re-invent PHAkt for that.
Is it the responsibility of the developer to inform the manufacturer of his tool that he will no longer use it? No.
I made my announcement public when I felt that I had no choice, and had received no support and or consultation. I don't think that in this respect Interakt have any such right in complaining about my actions.
Isn't this exactly what Interakt did 2 weeks ago? When they were informing select PHP Developers and Macromedia representatives that they were no longer going to support UltraDev or DWMX, because they felt they had received no support?
My main gripe was that four minutes after receiving an email with proposals for me to 'hand over' development of my extensions to Interakt, that Interakt were also making public announcements, that they would be re-engineering my work. Of course all of this was done before I had a chance to respond, and it could be argued that Interakt were trying to buy public support by name dropping.
The notion that I am trying to 'kill' you, is completely unfounded. That would indicate that there is some form of malice at work here. Yet quickly it is forgotten, that thanks to myself and other PHP Extension Developers, Interakt now have the product stable that they do. I was supporting PHAkT, long before there were any commercial offerings from Interakt, and continued to support them publicly and privately, though I did not receive the same in return.
> I must admit I'm shoked by his virulent response. He has already
> started with accusations on us, but I don't recall doing anything
> wrong with PHAkt (we are a small company and we have thought of
> abandoning developing PHAKt not long time ago, *from financial
> reasons*, but as PHAkt is free, this would not disallow other people
> to continue our work. However, our reasons were Macromedia related
> (they were ignoring us), and we have finally reached to understand
> each other)).
Alexandru. I have made no accusations. I have only quoted you. My virulent response was to your public (and private) proposal for 3rd party developers to 'hand over' to you previously release 'free' extensions and to integrate them into your COMMERCIAl model. This implies profiteering, and in my opinion is unethical and unprofessional considering you have engineered the situation that we are currently in.
> To deny some of Tim's accusations:
> - PHAkt2 is free
I have never, ever said that PHAkT is not free.
> - PHAkt2 uses Limited Recordsets. We have implemented our own version > of Paged Recordsets and ADODB recognized that Cached Recordsets are
> not very useful, so we have choosed to ignore them.
Except you have used them in QuB, so they do indeed have a use.
> - PHAkt2 will be much stabler than the previous versions.
I cannot comment on this.
> - PHAkt2 will support it's extension developers much better.
How do you propose to support it's extension developers better? At the moment we have received zero support from you at all. So anything would be better. Are you prepared to go on the record, and publicly commit to ensuring that 3rd party extensions will not break in future releases of PHAkT 2?
If you cannot do that. Will you publicly commit to informing developers in advance of release whether an extension will be broken in an upcoming release, and explain why?
Will you commit to retaining all Macromedia-established naming conventions and workflow methods so as to avoid the UD4/PHAkT Recordset.htm/RecordsetPHP.htm debacle, that consistently broke behaviors?
> - PHAkt2 will allow migration from PHAkt1 and from PHP_MySQL
This is an excellent idea, and I wholeheartedly support the use of migration engines of this type.
> - PHAkt2 will allow easy migration to our commercial products (and as > many of you can confirm, it's nothing wrong in providing more powerful
> solutions commercially, as we are making a living from extension
> development).
Absolutely. There is nothing wrong with this at all, providing that you are not trying to use your popularity to increase the product stable of your commercial offerings by devouring previously available free works.
> - PHAKT2 IS ALREADY IMPLEMENTED! and Macromedia is testing it right
> now for a release along with the MX final release.
Congratulations. I wish you every success.
> I alo suggest Extension developers to create their extensions for
> PHP_MySQL or for PHAkt2, as we'll provide them the tools to migrate
> between the server models. I use this opportunity to announce and
> release the "B Independent" migration > program, that will convert all > existing PHP_MySQL extensions for PHAkt2/ADODB, and viceversa.
This is an interesting proposal. One which I am sure will benefit many extension developers. One question regarding this, though. Considering the nature of many available extensions, this is a tall order. Who would be responsible for the support of converted extensions? If some form of migration system is implemented, how can support be guaranteed for such extensions when there is considerable difference between the two systems? Wouldn't this ultimately mean that the extension developer would have to learn both systems, and ultimately develop for them both, in order to guarantee their support levels?
I look forward to hearing your proposals.
All the best
Tim Green
Develop real purchasing power for your website with IntelliCART,
the PHP Shopping Cart Management System for UltraDev 4.
Tim Green
Extension & PHP TalkZone Manager
<font size=1>-------------------------------------------
<i>Please read the Forum FAQ before posting
a question to this TalkZone.</i>
-------------------------------------------
www.UDzone.com : A dynamic Dreamweaver,
Ultradev and Fireworks site for developers
by developers.
-------------------------------------------</font id=size1>
Replied 06 May 2002 23:55:43
06 May 2002 23:55:43 enquest enquest1 replied:
In my small philosophical opinion. You should call each other on the phone and work things out. Writing can get confusing and open for interpretation.
If you work togheter maybe you can do much more.
As long as the communication gets better -> And the Phakt version does not get mixed and hold back in favor for Impakt.
But this is a question of who leads the project, who is reviewing the code etc...
I hope that evrybody can get after one project.
If you work togheter maybe you can do much more.
As long as the communication gets better -> And the Phakt version does not get mixed and hold back in favor for Impakt.
But this is a question of who leads the project, who is reviewing the code etc...
I hope that evrybody can get after one project.
Replied 07 May 2002 12:30:15
07 May 2002 12:30:15 Interakt Online replied:
Hi,
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
In my small philosophical opinion. You should call each other on the phone and work things out. Writing can get confusing and open for interpretation.
If you work togheter maybe you can do much more.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We have started a separate/private conversation to clear thing our.
It seems that we had some communication missunderstandings, and we are working to resolve them in a civilized and useful fashion.
Alexandru
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
In my small philosophical opinion. You should call each other on the phone and work things out. Writing can get confusing and open for interpretation.
If you work togheter maybe you can do much more.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We have started a separate/private conversation to clear thing our.
It seems that we had some communication missunderstandings, and we are working to resolve them in a civilized and useful fashion.
Alexandru
Replied 07 May 2002 12:55:49
07 May 2002 12:55:49 Interakt Online replied:
Hello Tim,
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Is it the responsibility of the developer to inform the manufacturer of his tool that he will no longer use it? No.
I made my announcement public when I felt that I had no choice, and had received no support and or consultation. I don't think that in this respect Interakt have any such right in complaining about my actions.
Isn't this exactly what Interakt did 2 weeks ago? When they were informing select PHP Developers and Macromedia representatives that they were no longer going to support UltraDev or DWMX, because they felt they had received no support?
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
And we have made our point, and it seems that you have also made yours.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
My main gripe was that four minutes after receiving an email with proposals for me to 'hand over' development of my extensions to Interakt, that Interakt were also making public announcements, that they would be re-engineering my work. Of course all of this was done before I had a chance to respond, and it could be argued that Interakt were trying to buy public support by name dropping.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
I think that this was the greatest missunderstanding of all. We are known as ethical and respectuos developers, we have *never* done something that could be considered unethical.
In this respect, even if you have observed some annoying messages in my message, you should have considered us not guilty in the first place, and judge the final conclusion only after thorough discussion with us.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Alexandru. I have made no accusations. I have only quoted you. My virulent response was to your public (and private) proposal for 3rd party developers to 'hand over' to you previously release 'free' extensions and to integrate them into your COMMERCIAl model. This implies profiteering, and in my opinion is unethical and unprofessional considering you have engineered the situation that we are currently in.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
Tim, as I have explained you in private, we weren't targeted to make all of the extension commercial. We we willing to make some of them so, but this only with your consent and approval.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Except you have used them in QuB, so they do indeed have a use.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
This is a name missunderstanding. What we have in QuB is Recordset SQL query caching in a separate file, to avoid querying the database twice each time the recordset is loaded from the database. This is not the same thing as the ADOdb recordset caching.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
How do you propose to support it's extension developers better? At the moment we have received zero support from you at all. So anything would be better. Are you prepared to go on the record, and publicly commit to ensuring that 3rd party extensions will not break in future releases of PHAkT 2?
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We are working on something right now. We'll publish an announcement when we receive the answers from all our clients/partners.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
If you cannot do that. Will you publicly commit to informing developers in advance of release whether an extension will be broken in an upcoming release, and explain why?
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We will commit someone to supervise the extension compatibility, that's sure.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Will you commit to retaining all Macromedia-established naming conventions and workflow methods so as to avoid the UD4/PHAkT Recordset.htm/RecordsetPHP.htm debacle, that consistently broke behaviors?
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We have alredy did this in PHAkt2.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
This is an excellent idea, and I wholeheartedly support the use of migration engines of this type.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
That's why we create them <img src=../images/dmxzone/forum/icon_smile.gif border=0 align=middle>
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
> - PHAkt2 will allow easy migration to our commercial products (and as > many of you can confirm, it's nothing wrong in providing more powerful
> solutions commercially, as we are making a living from extension
> development).
Absolutely. There is nothing wrong with this at all, providing that you are not trying to use your popularity to increase the product stable of your commercial offerings by devouring previously available free works.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We regret it was interpreted this way
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
> I alo suggest Extension developers to create their extensions for
> PHP_MySQL or for PHAkt2, as we'll provide them the tools to migrate
> between the server models. I use this opportunity to announce and
> release the "B Independent" migration > program, that will convert all > existing PHP_MySQL extensions for PHAkt2/ADODB, and viceversa.
This is an interesting proposal. One which I am sure will benefit many extension developers. One question regarding this, though. Considering the nature of many available extensions, this is a tall order. Who would be responsible for the support of converted extensions? If some form of migration system is implemented, how can support be guaranteed for such extensions when there is considerable difference between the two systems? Wouldn't this ultimately mean that the extension developer would have to learn both systems, and ultimately develop for them both, in order to guarantee their support levels?
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We think that this won't be necessary. As we know exactly the changes needed from one system (PHP_MySQL) to another (PHP_ADODB), and because we have started to develop PHAkt2 starting with PHP_MySQL, we expect to have small changes in the extension (both GUI and generated code), that will be easiluy convertible from one to another. However, we'll supervise and support all the migrated extensions to make sure they will be perfectly compatible with the original one (we might even start a compatibility program : PHAKt compatible, that will certify that an extension was correctly migrated.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
I look forward to hearing your proposals.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
I am writing to you right now.
Alexandru
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Is it the responsibility of the developer to inform the manufacturer of his tool that he will no longer use it? No.
I made my announcement public when I felt that I had no choice, and had received no support and or consultation. I don't think that in this respect Interakt have any such right in complaining about my actions.
Isn't this exactly what Interakt did 2 weeks ago? When they were informing select PHP Developers and Macromedia representatives that they were no longer going to support UltraDev or DWMX, because they felt they had received no support?
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
And we have made our point, and it seems that you have also made yours.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
My main gripe was that four minutes after receiving an email with proposals for me to 'hand over' development of my extensions to Interakt, that Interakt were also making public announcements, that they would be re-engineering my work. Of course all of this was done before I had a chance to respond, and it could be argued that Interakt were trying to buy public support by name dropping.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
I think that this was the greatest missunderstanding of all. We are known as ethical and respectuos developers, we have *never* done something that could be considered unethical.
In this respect, even if you have observed some annoying messages in my message, you should have considered us not guilty in the first place, and judge the final conclusion only after thorough discussion with us.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Alexandru. I have made no accusations. I have only quoted you. My virulent response was to your public (and private) proposal for 3rd party developers to 'hand over' to you previously release 'free' extensions and to integrate them into your COMMERCIAl model. This implies profiteering, and in my opinion is unethical and unprofessional considering you have engineered the situation that we are currently in.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
Tim, as I have explained you in private, we weren't targeted to make all of the extension commercial. We we willing to make some of them so, but this only with your consent and approval.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Except you have used them in QuB, so they do indeed have a use.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
This is a name missunderstanding. What we have in QuB is Recordset SQL query caching in a separate file, to avoid querying the database twice each time the recordset is loaded from the database. This is not the same thing as the ADOdb recordset caching.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
How do you propose to support it's extension developers better? At the moment we have received zero support from you at all. So anything would be better. Are you prepared to go on the record, and publicly commit to ensuring that 3rd party extensions will not break in future releases of PHAkT 2?
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We are working on something right now. We'll publish an announcement when we receive the answers from all our clients/partners.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
If you cannot do that. Will you publicly commit to informing developers in advance of release whether an extension will be broken in an upcoming release, and explain why?
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We will commit someone to supervise the extension compatibility, that's sure.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Will you commit to retaining all Macromedia-established naming conventions and workflow methods so as to avoid the UD4/PHAkT Recordset.htm/RecordsetPHP.htm debacle, that consistently broke behaviors?
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We have alredy did this in PHAkt2.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
This is an excellent idea, and I wholeheartedly support the use of migration engines of this type.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
That's why we create them <img src=../images/dmxzone/forum/icon_smile.gif border=0 align=middle>
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
> - PHAkt2 will allow easy migration to our commercial products (and as > many of you can confirm, it's nothing wrong in providing more powerful
> solutions commercially, as we are making a living from extension
> development).
Absolutely. There is nothing wrong with this at all, providing that you are not trying to use your popularity to increase the product stable of your commercial offerings by devouring previously available free works.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We regret it was interpreted this way
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
> I alo suggest Extension developers to create their extensions for
> PHP_MySQL or for PHAkt2, as we'll provide them the tools to migrate
> between the server models. I use this opportunity to announce and
> release the "B Independent" migration > program, that will convert all > existing PHP_MySQL extensions for PHAkt2/ADODB, and viceversa.
This is an interesting proposal. One which I am sure will benefit many extension developers. One question regarding this, though. Considering the nature of many available extensions, this is a tall order. Who would be responsible for the support of converted extensions? If some form of migration system is implemented, how can support be guaranteed for such extensions when there is considerable difference between the two systems? Wouldn't this ultimately mean that the extension developer would have to learn both systems, and ultimately develop for them both, in order to guarantee their support levels?
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
We think that this won't be necessary. As we know exactly the changes needed from one system (PHP_MySQL) to another (PHP_ADODB), and because we have started to develop PHAkt2 starting with PHP_MySQL, we expect to have small changes in the extension (both GUI and generated code), that will be easiluy convertible from one to another. However, we'll supervise and support all the migrated extensions to make sure they will be perfectly compatible with the original one (we might even start a compatibility program : PHAKt compatible, that will certify that an extension was correctly migrated.
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
I look forward to hearing your proposals.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
I am writing to you right now.
Alexandru