COAL Caching change

[Ryan Guill]

Well guys, Ive got to admit something.

I had an epiphany of sorts today after a conversation on cf-talk. Its
something that I have known for a long time in the back of my mind,
but never fully realized it. First a little background.

You cannot duplicate or copy components. Components (objects) are
passed by reference, not by value. And the duplicate() method doesn't
work on objects. If you aren't with me, consider the following code.

<cfset variables.x = createObject("component","myObject").init() />

<cfset variables.y = variables.x />

If objects were passed by value, variables.y would hold its own copy
of the object. But since objects are passed by reference, variables.y
and variables.x hold the exact same object. So If we make a change in
variables.y, the change was also made in variables.x.

So why is this a problem? Because in COAL, I implemented part of the
service locator pattern that is the caching agent. Which makes sense
in the service locator pattern, because the pattern is working with
_services_, not objects. Services are stateless. You can create
objects out of them, but they should have no instance data. They are
also singletons, and only one copy should exist per application. So
if the code was to request a service that has already been created, it
should give them the exact same copy of the service, not a new one.
But this doesn't work with the objects that COAL is supposed to
create. So basically the caching agent in COAL is useless, and should
not be used.

I haven't run into any problems with COAL yet though, because I always
turn caching off anyway. But I am sure if I was using the caching, it
would have caused problems by now.

So, sorry for that long explanation, but this is whats going to
happen. The service locator pattern is still great for COAL in the
way that you can request just the object name (that you have given it
in the config xml document) and get it to know where the component is
stored and create the object for you. So we are just going to take
the caching agent out of the "framework" code. I am going to leave
the cache attribute in the coal.cfc init() for now for backwards
compatibility, but it will basically be disabled, no matter what you
give it there will be no cache. So the implementations you already
have wont break, just that functionality (which is and should be
transparent at this point anyway) will just cease to exist. You
should go ahead and take that attribute out if you are using it now
because it will be taken out completely in future versions.

Sorry about this dumb mistake guys. But it should all be fixed pretty
easily by this weekend. Any comments or suggestions on the matter are
welcome.

--
Ryan Guill
BlueEyesDevelopment
ryan...@gmail.com
www.ryanguill.com
(270) 217.2399
got google talk? Chat me at ryan...@gmail.com

The Coldfusion Open Application Library - COAL - http://coal.ryanguill.com

www.ryanguill.com/
The Roman Empire: www.ryanguill.com/blog/

[ryan...@gmail.com]

I just want to stress again, I am going to be planning up untill
thursday night possibly friday afternoon and then starting friday
evening I will be making the changes to COAL. I will most likely go
through every line of code in COAL as it is, so if you have any feature
requests, change requests, bug reports or anything else you would like
me to know or think about before this update, please let me know asap.

[ryan...@gmail.com]

Quick update guys,

I have rewritten COAL (every line actually, and it works beautifully),
removing the caching agent and adding in support for mappings to coal
other than "coal". So far so good. Also, everything seems to be fully
backwards compatable as well, so if you are already using COAL, all you
will have to do is to back up your config.xml file and any components
that you have added and then overwrite the framework. I am going to be
testing it a lot more through the rest of the week and the weekend. If
anyone has any feature requests, bug reports or any other concerns in
the meantime, please let me know.

Also, Bill, If you want to get with me on the config xml about any
elements or attributes that we might want to add or tweak that would be
good. We also might be able to go ahead and try to at least get a
little bit of 'proof of concept' on your updater going as well.

Thanks guys, and please let me know if you have any questions, comments
or suggestions.

[Bill Rawlinson]

good point. I have only begun to outline it so far. I was hoping to
get some good work on it next week when my wife is out of town for
five days. I was thinking the server end could be two components..
one a webservice that you poll for updates/new components. The other
you HTTP post to and it returns you the zip file with the components
in it.

CoalVersionManager
and
CoalComponentManager

or something along those lines; the component manager could
theoretically be extended later to support getting component
submissions if you ever wanted to go that route.

i think getting the actual server components done or at least stubbed
out, is the
best way to go; then i can throw together a simple prototype client
for the proof of concept..

I'll email you tomorrow with the methods I think both components need.

Bill

--
bill.ra...@gmail.com
http://blog.rawlinson.us

If you want Gmail - just ask.

[Ryan Guill]

Bill,

I have done a little bit of work on this last night. I think you had
told me at one time that you did not yet have COAL installed, so if
you want to get a gander at what the config xml looks like, you can
hit http://coal.ryanguill.com/updater/current.xml to see an example.
I have already got some code that is going out there, getting the xml,
parsing it, and now I just have to compare it with what is installed.
Its going to be quite easy I think. The hardest part I imagine is
giving them the chance to download only the selected components, but
one step at a time I guess.

[Bill Rawlinson]

i think the "only the selected" components part wont be too difficult
so long as we have a good way to identify each component they want
(and then where it is on the server) zipping them up and pushing them
back should be pretty straight forward.

[Ryan Guill]

Yeah, I think its the unzipping and placing the file in the right
place and editing their config xml file that Im a little worried
about. But it shouldn't be too bad.

I am adding a public method to COAL to get the config xml directly out
of the service as well.

[John Farrar]

Is there a way to configure COAL with an XML that isn't listed as XML. I
like to make sure that I can block the crafty hacker from reading a
configuration script. I like to store my files in .cfm format. Then I start
them with an underscore and inside Applcation.cfm I check to see if the
called script started with an underscore. If it does than I just abort the
call.

[Ryan Guill]

umm, im not sure because i haven't tested it, but you could change it
to a .cfm file if you wanted. But honestly, this really shouldn't be a
problem because all you will have to do is put coal in a directory not
accessible from your web server. Then just make a mapping to it in
the cfadministrator and it will just work, but you wont be able to
access it from the site.

It is because of this reason that for this update script the developer
is going to have to create their own page in their website and put
this code on it:

<cfinclude template="/<coalmapping>/update.cfm" />

or something similar.

[John Farrar]

I write frequent applications to be deployed on Shared Hosting services
where the mapping issue is dependent on the provider. My approach is to not
have to have myself or someone using software that I build dependent on the
cooperation of these guys. (Other than that I agree.)

So... thanks for the option! That is super... and looking forward to doing
some Coal minning.

John Farrar

[Ryan Guill]

Well in those situations, if you are using cf7 (and I believe there
were "hacks" in 6.1) with the new admin api, you could write a script
that will get a list of all the mappings and create your mapping in
code. Would that fix your problem in the shared hosting? I dont know
though, the admin api might be something that the hosts could turn off
in the administrator...

[Ryan Guill]

I also want to point out real quick too that when you are creating
your COAL connection, you have the choice to pass in the location of
the COAL xml configuration file. So you could two things with that,
you could remove this file to any location you want and pass that
location in, and you could also rename the /config/coal.xml to
/config/_coal.xml if you wanted and pass that in. Then you should be
able to do your check like you had mentioned in the application.cfm
file to make sure that if someone is requesting the file through the
browser to disallow it. This should not affect COAL processing
either. Just a thought I just had.

On 9/30/05, Ryan Guill <ryan...@gmail.com> wrote: