Ok first off all the answer is not as complicated as you have made it....

Ok I have here running the tag that allows me to share CF varaibles with
ASP, I don't do anything as complicated as you think... But I can tell you
know that if there was a tag like cfa_dump on ASP, that could dump session,
application etc then I have the code waiting but I just need that answered.

I would be more than happy to release the code, but I would like to see if
people know of being able to know what variables are in ASP without actually
knowing. Which is what cfa_dump does for cf's collections
(server,cgi,form,application etc.), it really is a piece of cake for it to
work for CF but not for ASP...

I believe the approach I am looking at will work more efficently than the
method you seem to be describing below.


-----Original Message-----
From: Eric Barr [mailto:[EMAIL PROTECTED]]
Sent: Friday, 23 February 2001 11:46 PM
To: CF-Talk
Subject: RE: Strengths of each


This discussion sure seems to be describing the reason we have client
variables in CF, particularly when using as DB as the store.

In CF Client variables were created so that two CF servers that have
very little knowledge about each other (maybe a heartbeat in the
clustering software) need to be able to share information.

In the old days of web development coders had to write their own session
management, because it was not built into many scripting engines.  All
you really end up doing is sending a cookie with a unique value to each
user.  So that way, each time you get a request from the user you can
check their cookie and determine which user is making a request.   You
created some sort of clever naming scheme in the Application scope to
associate a set of variables with the unique cookie you sent to the
user, thereby you can crate a "session level" storage system.

To Share information between ASP and CF you need to do something
similar.  You need to create a clever way that both CF and ASP can
uniquely identify a user, then associate the user with an area of
storage.  Since CF and ASP don't share a memory space there are two ways
to go:
1) creative use of URL's
2) use a common storage area (read database)

The more robust solution of the two is probably using the database as a
storage mechanism.

If I had to implement this system I would probably let CF take the lead.
By that I mean, CF already has Client variable storage built in, and it
works well, so leverage CF's capabilities so this way you only need to
implement a system in ASP.

In ASP you would need to write a block of code that could be used on
each page, most likely setup as a set of functions that are added as an
include file on each page.  This code would have to:

1) read the CFID & CFTOKEN from your users cookies
2) if no CFID & CFTOKEN ...redirect to CF page that simply sets the
cookies, then bounces back to the original ASP page
3) Make a DB connection to the common storage tables
4) Pull the information from the database.
5) either parse the WDDX packet by hand, or use the WDDX COM object for
ASP.
6) use the data as you see fit

Implementing a system like this would definitely require some testing
and a good deal of debugging, but it would probably be worth while.  As
with any other coding technique there are performance implications with
this one, but none that can't be overcome. Developer take a performance
hit when using Client variables in CF, but the benefits of being able to
have state maintained across multiple machines in a web farm outweigh
the performance hit. (BTW client variables are a well designed solution
by Allaire: they are  really, really fast)

Take it one step further the ASP server dosen't even need to be on the
same server (as long as domain cookies are begin set )as the CF server.
In fact it dosen't even need to be ASP, it could be PHP, JSP, shoot it
could be Tango running on a Apple's Webstar. How freaky is that ?  The
major limitation I see on this system is the user would have to hit a CF
page first, so they have a CFID & CFTOKEN.

Microsoft has some pretty good articles that might give perspective on
the discussion here :
1) http://msdn.microsoft.com/workshop/server/feature/webfarm3.asp
2) http://msdn.microsoft.com/library/periodic/period00/stateless.htm
3) Article ID: Q175167


I hope this helps answer some of the questions out there.

-eric
------------------------------------------------
Common sense is genius dressed in its working clothes.
 -- Ralph Waldo Emerson

Eric Barr
Zeff Design
(p)  212.714.6390
(f)   212.580.7181


-----Original Message-----
From: Scott, Andrew [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 23, 2001 12:38 AM
To: CF-Talk
Subject: RE: Strengths of each


I had also started to adoipt something like this, but sometimes time is
not
very kind to some...

Anyway my main concern would be the overheads off pulling this
information
out all the time, yet when I did stop to think about it I would assume
the
overheads would be similar to using client variables and having this
stored
into a datasource...

Would I be right on this?


-----Original Message-----
From: Nick McClure [mailto:[EMAIL PROTECTED]]
Sent: 23 February 2001 16:12
To: CF-Talk
Subject: RE: Strengths of each


One of the things that I have been working on recently is My own
Session/Application management System.

All variables are stored in the database, VBScript functions and CF
Custom
Tags are used to pull these variables. This system was designed to
easily
be ported to any Language. If for some reason we wanted to add a JSP or
C++
portion to a given application, it could continue to use the same
session
info.

Right now I am in the early development stages, so a lot of stuff has to
be
done twice, but I plan to move most of it into stored procs.


>To answer your first question, yes, CF and ASP can coexist on the
server,
>there are no problems having a mix of ColdFusion and ASP pages within a
>site, however, I'm pretty certain you can forget sharing Session and
>Application variables between these environments.  But you could pass
>variables through on URL's.
>
>We tend to write CF only sites now, while we used to be mainly ASP
>developers, however we've never needed to mix the two.
>
>Hope this helps a little bit.  Feel free to contact me off list if you
have
>any further questions.
>
>Nick
>
> > From: "Terry Troxel" <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > Date: Thu, 22 Feb 2001 11:09:31 -0800
> > To: CF-Talk <[EMAIL PROTECTED]>
> > Subject: Strengths of each
> >
> > I am posing a question that has been rattling around in my mind for
>awhile.
> > My host runs on O'Reilly WebSite Pro, so I have zero exposure to IIS
and
> > maybe that is why I m in the dark.
> > I would like to know if CF and ASP can co-exist and possibly trade
data
>like
> > CF does with javascript, WAP, etc.
> >
> > The second part of my question is if this is possible has anyone
compiled
>a
> > list of what types of procedures, functionality is best handled by
which.
> >
> > If these questions are true then I have to get onto an IIS host, and
start
> > learning ASP to broaden my skills. I assume this is the path alot of
you
> > have taken by the frequency of ASP and CF in your signatures.
> >
> > Terry Troxel
> >
> >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm

Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Reply via email to