[thelist] cf vs asp

[Daniel J. Cody]

Scott Dexter wrote:
> 
> 
> > - With ASP you don't get a lot of built in functionality. For instance
> ...
> > so the functionality of CF is beyond ASP in that sense.
> 
> nnnnnnnope. Look at it the other way around. You can write your own dll to
> do whatever you want, and call it from ASP. I know at this point CF must be
> able to instantiate COM objects, but ASP functionality is *not* reduced
> because ASP doesn't have things built in. Recall what Adrian said; ASP is

I think adam was trying to say that CF has many of those functions you
have to write for ASP *already* built in. Things like SMTP, POP, LDAP,
and FTP handling to name a few. Sure, you can write a custom DLL in asp
to do the same thing, but why re-invent the wheel?

Just to clarify, you *can* write your own custom tag or COM, Java,
CORBA, or C++ object with CF and integrate that into your application
just as seemlessly as ASP could.

> closer to the underlying OS, and while that may mean things aren't built in,
> it also means a faster path for execution and the ability to get at whatever
> you want....

The flip side to that of course, is you inherit the flaws of the OS
you're so closely tied into. Without getting into *that* whole issue
though..

> > - (correct me if I'm wrong on this) We had to use ODBC to connect to
> > Oracle and SQLServer from ASP.  ODBC isn't a super efficient way of
> > connecting so that could be a disadvantage performance-wise.
> 
> You can specify the OLE-DB provider to connect to the DB, and it is much
> faster than ODBC.
> example (all on one line):
> "Provider=SQLOLEDB.1;User ID=IISUser;Initial
> Catalog=Foo_db;Password=blahablah;Server=LocalServer"

Native connections like OCI(oracle native call internface) will smash
OLE or ODBC, which I think is what adam was trying to elude to.

.djc.