PHP development for MX - the response of InterAKT
Alexandru COSTIN
There were a lot of discussions on the vision on PHP developm
ent in Macromedia MX.
People (users and extension developers) were complaining on the con
fusion that reigns over the PHP development choices. We are (alon
g with Macromedia) in the "guilty" section.
We have released too many server models, ideed. And if for the UD4 v
ersion 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, alon
g with Macromedia's original one: PHAkt2. PHAkt2 will be the core for a
ll our extensions (ImpAKT will become a suite of server behaviors, NeXTensi
o 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 wi
th the code (by avoiding manual code modification), you will be able to m
igrate your existing sites to the latest PHAkt version.
I will also comment another disturbing trend we have detected o
n this lists. Tim Green, once our strongest ally, now wants to remove us fr
om the market, releasing it's own server model. (on the udzone PHP talkzo
ne 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 mu
ltiple 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 refe
rences to mysql_* all over the place, and overloading native PHP function
s with the same parameters is not possible in the current PHP implementati
on (as far as we have researched this). So it's utopian to think th
at the PHP_MySQL server model can be transformed into an database indep
endent 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 w
e were undecided to create PHAkt2, but MM is helping us and we are ac
tively working on finalizing it - free. Tim's reasons for it's server mod
el are not very convincing to us, as we are willing to correct most of ou
r 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 extensio
ns (he announced on udzone, *without* telling us first, that he will dr
op the support for PHAkt/ImpAKT). We don't understand him at all. We migh
t 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", "da
tabase independence". We already have this in PHAkt2. It's free to use, f
ree to redistribute and free to modify. The LGPL license is less restrict
ive on the "free" side, because it allows commercial updates to be releas
ed and the code doesn't have to be reported to the original developer. W
e 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 s
tarted 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 r
easons were Macromedia related (they were ignoring us), and we have f
inally reached to understand each other)).
To deny some of Tim's accusations:
- PHAkt2 is free
- PHAkt2 uses Limited Recordsets. We have implemented our own vers
ion of Paged Recordsets and ADODB recognized that Cached Recordsets are no
t 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 a
s many of you can confirm, it's nothing wrong in providing more powerful sol
utions commercially, as we are making a living from extension development).
- PHAKT2 IS ALREADY IMPLEMENTED! and Macromedia is testing it right n
ow 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 o
ffer a much greater support to our extension developers, because we have fal
len in the same trap MM did : ignored the people that write extensions f
or 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 betwe
en 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 ba
d news today and I am also in a holliday today:), 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 ext
ension developers (by InterAKT or with automated tools, we will investiga
te the right way)
- PHAkt1->PHAkt2, PHP_MySQL->PHAKT2 migration engines.
I will leave the office now, I will respond on this thread to
morrow morning. Let's hope we'll reach a consent that will please the user
s, the extension developers and us.
Alexandru
--
-----------------------
Alexandru COSTIN
Product Manager
http://www.interakt.ro/
+401 411 2610
Brent Colflesh
Thanks for explaining your position and plans!!
Regards,
Brent
"Alexandru COSTIN" <aco...@iakt.rdsnet.ro> wrote in message
news:ab60hf$n2o$1...@forums.macromedia.com...
Thomas Muck
releasing two server models. I think that was a major problem last time for
many of us. For one, people who tried to use our extensions were upset when
they didn't work in ImpAKT. Changing the filenames from the standards
(Recordset.htm became RecordsetPHP.htm) was not a good idea either. Maybe it
had to be done because of limitations in UltraDev, but it made it very hard
to maintain extensions. I think we are all much wiser now, and hopefully
solutions can be reached for all parties.
"Alexandru COSTIN" <aco...@iakt.rdsnet.ro> wrote in message
news:ab60hf$n2o$1...@forums.macromedia.com...
Alexandru COSTIN
> Thank you for the update. I think you have made good decisions as far as
> not releasing two server models. I think that was a major problem last
> time for many of us. For one, people who tried to use our extensions were
> upset when
> they didn't work in ImpAKT. Changing the filenames from the standards
> (Recordset.htm became RecordsetPHP.htm) was not a good idea either. Maybe
> it had to be done because of limitations in UltraDev, but it made it very
> hard to maintain extensions.
We are aware of that. Thanks for your support.
Once again I express my regret that we didn't thought this over fr
om the beggining. However, we were much younger and unexperienced and ti
me has made us (i hope) more clever.
> I think we are all much wiser now, and
> hopefully solutions can be reached for all parties.
We are also discussing with all parties involved to find a clever so
lution for everyone's needs.
We are hoping we'll reach the public consent soon.
Alexandru
>
> tom
> www.dwteam.com
>
> "Alexandru COSTIN" <aco...@iakt.rdsnet.ro> wrote in message
> news:ab60hf$n2o$1...@forums.macromedia.com...
>> Hello,
>> There were a lot of discussions on the vision on PHP developm
>> ent in Macromedia MX.
>> People (users and extension developers) were complaining on the
> con
>> fusion that reigns over the PHP development choices. We are (alon
>> g with Macromedia) in the "guilty" section.
>> We have released too many server models, ideed. And if for the
>> UD4
> v
>> ersion 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, alon
--
Tim Green
> 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
t...@rawveg.freeserve.co.uk
Develop real purchasing power for your website with IntelliCART,
the PHP Shopping Cart Management System for UltraDev 4.
Massimo Foti
> > I think we are all much wiser now, and
> > hopefully solutions can be reached for all parties.
> We are also discussing with all parties involved to find a clever
so
> lution for everyone's needs.
> We are hoping we'll reach the public consent soon.
I think a crucial point is also to let all the major players involved before
taking any decision that may impact other developers.
Massimo