Ah yes, but ASP is "free", with upgrades. I'm sure you've looked at some
of the new features in ASP+
But, as you say, it may be that this community expects more, or rather, has
different expectations. ASP is a framework for using COM/DCOM objects
to get the "real" work done. Developers who work with VB and ASP a lot are
used to
accumulating a toolbox of objects that do what the developer needs or
reusing ones
that come with the OS/Apps/etc. CF originally came with a couple of these
"objects"
pre-installed. The community that grew around CF did so with a prior history
of
inclusion. Also, CF didn't have external object support until v.3.x. and
that
wasn't/isn't top notch. I am just starting to see wide-spread use of native
OS/App objects
with CF. I think that this is partly due to people's lack of knowledge and
awareness
of what's there and also because many of these objects are limited by
operational req's
(install Word on the server), and the limitations of CFOBJECT (no complex
data types).
WARNING: Exaggerated use of CFHTTP as an example follows -> Debugging
CFOBJECT and/or
dealing with it's limitations shouldn't be a developer's first step in
finding a CFHTTP
replacement. Because of CFOBJECT's limitations this might be an issue. Also,
CF developer
shouldn't have to learn C++/Delphi and the CFX API, as easy as it is, just
to get reliable
HTTP support. This goes against your argument from earlier today in which
you argued that
one of CF's advantages over ASP is not having to deal with ASP's HTTP
functionality.
If I were to write a CFX tag or COM object to fix this particular problem
I'd need to know
a heck of a lot more about HTTP than ASP requires. In other words, if CF is
gonna shield
you from low level code/constructs it should do so reliably. If Allaire says
they're shipping
a product with x, y, and z functionality then I shouldn't feel the need to
find a plugin
replacement for 'y' because theirs doesn't do it right. If your example ASP
developer bought
a third-party COM object to get HTTP support and that object didn't work
right would you
expect him to keep using it without bitching all the time? :)
I should end by saying that I feel this applies only to what I see as core
functionalities like
HTTP, database access, RegEx, etc. and those emerging technologies which
will inherently benefit
the advancement of information systems and/or the global electronic economy.
Overly simple examples
of these two are XML (WDDX) and SSL (HTTPS), respectively. An authtication
module for RADIUS,
though, would fall under the realm of third-party purchase or internal
CFX/COM development.
Steve
-----Original Message-----
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 28, 2000 3:13 PM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: RE: What I want in CF (was: Learning ASP)
> 7. Fix CFHTTP!
I agree that it's not as good as it could (or should) be. I'd generally
recommend a third-party product for serious HTTP client needs.
This brings up an interesting point. As CF developers, we're used to getting
lots of functionality in the base CF product, without having to rely on
third-party addins. Is this what we should expect?
For example, I'd much rather have the CF developers fix other problems
within CF, such as memory management and stability issues, or the COM
interface, than fixing CFHTTP, CFMAIL, and the rest, because those I can
replace on my own. I can't do a whole lot about how CF manages memory,
though.
Maybe our expectations are a bit high, after all. I suspect you wouldn't
hear ASP developers complaining about the lack of HTTP client functionality
built into ASP; they expect to have to use third-party products to fill
functionality gaps. Why should CF developers be different in that regard?
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
