John Passaniti
|
| Posted: 07/05/2001, 9:48 PM |
|
This question may have been asked before, but I can't easily find a
response.
I'm interested in knowing the relative priorities the CodeCharge developers
have when it comes to supporting existing and new environments. For
example, the 1.2 beta currently only supports ASP/VBS with templates. This
suggests to me that ASP/VBS with templates represents the highest priority
environment for CodeCharge. But maybe not.
I ask because I'm kind of worried. I purchased CodeCharge because my
preferred environment is Perl. But I have no idea what level of priority
CodeCharge places on that environment. It's reasonable to expect that
environments that only a minority of customers use might one day be dropped
or would take longer to be supported in future versions of CodeCharge.
|
|
|
 |
Steven Dowd
|
| Posted: 07/06/2001, 3:58 AM |
|
John ,
I think you will find easily in the posts by codecharge on the v1.2 subject
that they made it available in ASP first only because the dev work is done
in ASP then converted to all other code variations , php perl cf etc etc.
I do not think that they released in ASP to show there unwillingless to
support the other code enviroments , just ease of development,
Steven
"John Passaniti" <nntp@JapanIsShinto.com> wrote in message
news:9i3fv8$io3$1@news.codecharge.com...
> This question may have been asked before, but I can't easily find a
> response.
>
> I'm interested in knowing the relative priorities the CodeCharge
developers
> have when it comes to supporting existing and new environments. For
> example, the 1.2 beta currently only supports ASP/VBS with templates.
This
> suggests to me that ASP/VBS with templates represents the highest priority
> environment for CodeCharge. But maybe not.
>
> I ask because I'm kind of worried. I purchased CodeCharge because my
> preferred environment is Perl. But I have no idea what level of priority
> CodeCharge places on that environment. It's reasonable to expect that
> environments that only a minority of customers use might one day be
dropped
> or would take longer to be supported in future versions of CodeCharge.
>
>
>
|
|
|
|
John Passaniti
|
| Posted: 07/06/2001, 9:02 AM |
|
"Steven Dowd" <steven.dowd@dowd.co.uk> wrote in message
news:9i45ko$rct$1@news.codecharge.com...
> I do not think that they released in ASP to show there
> unwillingless to support the other code enviroments ,
> just ease of development,
That doesn't really address my question.
In past message threads, we saw that CodeCharge decided not to support
specific environments (I believe an earlier version of ColdFusion was
listed, and a question about Python may have been asked). The response was
fine-- that the people using those environments are a tiny minority, and
CodeCharge can't support everyone. I don't have a problem with that, but it
does beg the question of priorities.
For example, I use CodeCharge to target Perl with templates. If it turns
out that only a small minority of people use CodeCharge to target that
environment, it is reasonable to assume that at some point CodeCharge will
drop support for it. I'm not asking the CodeCharge folk to have a magic
crystal ball and tell me their plans for the next dozen years. But I would
like clarification on what priority they put on each environment.
(Frankly, this really is only an issue for two reasons-- the level of
abstraction in their code generation patterns appears to be too low, and
they don't open up the development process. If CodeCharge came up with the
ability for end users to make code generation patterns, it would allow them
to use the user community to support minority environments. It would also
allow for much faster development. CodeCharge could always offer their own
code generation patterns for the platforms they support, but they could also
point to third-party sources for other platforms. They could end up selling
CodeCharge not only to end developers, but meta-developers as well.)
|
|
|
|
|
