Each week from now until the Fusebox conference (Aug
31 - Sep 1), we're talking with one of the conference speakers.
WEEK 3: John Quarto-von Tivadar
FB: We're talking with John Quarto-vonTivadar this week.
John is
speaking on plugins and security at the upcoming Fusebox conference.
John is also one of the authors on the upcoming "Discovering
Fusebox 4"
book from Techspedition Press (techspedition.com). So, John,
what is
a "plugin"?
JQ: It's a way of extending the core functionality of Fusebox.
When
Fusebox 3 was released, we saw that people had special needs
that
they wanted handled by the Fusebox core files. They had to
change the
core files to meet those needs and of course, that introduced
problems.
FB: What sort of problems?
JQ: Well, one of the advantages of Fusebox is that it is
a well-known
standard. It means that my code can work with your code, pretty
much
seamlessly. But if, when we say "Fusebox", we're
talking about two
separate things-
FB. Which happens if you have different core files.
JQ: Exactly. And when that happens, it means that interoperability
goes
out the window. It also means that the code you write for
one version
almost certainly won't work with the next version.
FB: You're talking about versions of Fusebox?
JQ: Yes. If you write your code counting on some functionality
in
Fusebox that's there because you changed the core files, then
when
version 4 comes out-
FB: Which is out now.
JQ: Yep, officially released. Anyway, when Fusebox 4 was
released,
then the old code wouldn't work with the new version.
FB: And plugins solve this?
JQ: Yes. They solve it because Fusebox 4 is made to accommodate
those changes. Fusebox 4 has "plugin points"-different
phases of the
code which will include any plugin code you write, making
them, in
effect, part of the core files. When there's a new version,
you just drop
your existing plugins in and you're up and running.
FB: That does sound like a great idea. What exactly is a
"plugin point"
though?
JQ: There are certain points in the processing of a Fusebox
request that
we identified as points where someone might want to insert
some code.
For example, there's a "preprocess" plugin point.
Any plugins that are
registered to run in the preprocess phase will be included
before virtually
anything else happens in the processing of a fuseaction request.
FB: So there's probably a "postprocess"?
JQ: Right. We identified all of the points we thought would
make sense.
There are a total of six of them. One thing that will interest
people is
that one of the phases is "fuseactionException".
When an exception is
thrown, the core files will check to see what plugins are
registered and
will pass control to those plugins. That means that we have
a really nice
way of doing exception handling-something that was lacking
in Fusebox
3.
FB: That's very nice.
JQ: It does work very well. We're really pleased with Fusebox
4.
FB: So what about security? How did that get built into the
core file?
JQ: We thought for a long time about security. The problem
is that
there is no universal security model. But we didn't want to
just punt the
ball. Security is too important. What we did was introduce
an attribute
to the new <fuseaction> tag called "permissions".
That allows architects
to provide a value that will be available to the core files.
FB: And the core files then check the value of "permissions"
with a
database of user permissions?
JQ: Well, that might be the way that you would want to handle
it, but
then again, you might have a completely different mechanism.
It's why I
say there's no universal security model that fits everyone.
Instead of
Fusebox trying to impose a one-size-fits-all solution, we
provide
this "permissions" attribute and then let the architect
determine what to
do with that in a.
FB: In a what?
JQ: That's your cue. Your supposed to jump in with the right
answer.
FB. Oh. Um.in a "security module"?
JQ: Yes-sort of. And how would that security module be implemented?
FB: In a plugin!
JQ: Exactly. It's a perfect application for a plugin. Security
can be as
simple or as complex as you wish it to be. And you only write
one
security module, as you called it, and it will be applied
for all
fuseactions
that you wish.
FB: What if I don't want any security applied at all?
JQ: Just don't register any security plugin. It's not like
you'll pay any
performance penalty. The value, if any, of the "permissions"
attribute
will just be ignored. For that matter, the "permissions"
attribute, itself,
is
optional.
FB: I'm seeing that plugins can be very powerful.
JQ: Yes, and just as importantly, they are very simple to
implement.
Plus, there are already pre-built plugins available.
FB: You're going to be sharing tips and tricks on plugins
and security at
the conference?
JQ: Yes, I've got a fun application that graphically shows
how to create
a pretty involved security model. And we'll see how plugins
can span
phases-all sorts of cool stuff.
FB: Where do people sign up?
JQ: That would be at www.cfconf.org/fusebox2003.
FB: And if people want to buy a copy of your new book?
JQ: It will be available at the conference or you can buy
it from
techspedition.com. People preordering the book will get a
25% discount.
Of course, there's a way to get the book for free.
FB. What's that?
JQ: Hal and I are doing a "FastTrack to Fusebox 4"
class in Las Vegas
immediately prior to the conference. Come to the class (halhelms.com)
and you'll get a free book AND a pass to the conference.
FB: Thanks, John.
Previous weeks:
Week 1: Ben Edwards
Week 2: Michael Smith
Week 4: Hal Helms
Week 5: Jeff Peters
