> This brings me to the event gateway, which is supposed to liberate
> CFML from
> HTTP. Sure there are tons of reasons why you would want to have a
> CFML-based
> web application integrate with protocols other than HTTP. I have
> integrated
> CFML-based web applications in the past with a variety of protocols
> without
> the support of an event gateway. Certainly it would have been easier
> and
> more elegant with an event gateway, but I am not so sure the event
> gateway
> is the missing piece. To me, it seems the missing piece is the
> ability to
> invoke CFML from other sources than an HTTP request. While the event
> gateway
> will provide that, it seems it will also provide more than that.
Ahhh... I understand what you are saying -- you want ti invoke a CFM or
CFC directly. from outside CFMX without the indirection/overhead of
listening for and triggering an event.
That's certainly valid!
I can think of several places where this approach would be superior.
But that doesn't negate the value of an event gateway.
That said, it should be possible to implement Both ways of invoking a
CFC/CFM---
Isn't what you want an API that provides the same interface that (part
of) the event gateway uses to invoke the CFC?
If so, I suspect that it would be relatively easy (from a technical
standpoint) for Macromedia to provide that API.
Whether that is in Macromedia's best interest is a consideration.
Because what you are asking for is the ability to incorporate CFML
Classes (CFCs, CFMs) into a Java (or other) program.
Does that mean that your package includes:
1) Your Java app
2) Your CFMs & CFCs
3) The CFMX/Blackstone Redistro jar
I can see this as being viable as long as the manufacturer (Macromedia
in this case) can make acceptable income on 3.
> Do we really need a whole bunch of infrastructure to allow invocation
> of
> CFML from other sources? I don't think we do. The reason I feel that
> way is
> because I think it is far too easy for the community and 3rd party
> companies
> to provide various protocol adapters. With a simple Java API for the
> invocation of CFML it would be quite easy for someone with Java
> experience
> to write these adapters. Whether Macromedia or someone else supplies
> event
> gateways or protocol adapters is of little importance to the average
> CFML
> person. In either case, someone with Java expertise must create them
> and
> your average CFML developer will just make use of them.
True, but...
There are are a series of events that occur within the CFMX system,
itself.
Logically, it seems that it would be easier to process these with an
enternal event gateway, rather that attempt to do this from outside the
system.
The set of applications that monitor things internal to CFMX and
application activity come to mind.
Consider that you you could write a fantastic performance
monitoring/tuning/debugging tool.
Certainly you could that external to CFMX, but it would likely be
easier with an event gateway (where you could intercept events without
consuming them).
And, yes, you would need to write some Java code to do this ... unless
we have something like cfmessage that allows us to setup the listener
- processor linkage.
>
> The real difference is constraints placed on the implementation by
> the event
> gateway. We have already heard that the event gateway will invoke CFC
> methods. What if we don't want CFC methods to be invoked? Will we
> have to
> write CFCs that then in turn call CFMs? What if the event gateway
> framework
> makes assumptions that aren't true for all protocols thus making it
> hard or
> impossible to implement some other protocol Macromedia didn't think
> about?
> All of these problems go away if there is a simply Java API for the
> invocation of CFML. Heck, Macromedia can even supply a bunch of
> protocol
> adapters if they want; they just don't need to create a framework and
> force
> it on others. Not only that, but if Macromedia didn't spend time on
> building
> stuff the community is perfectly capable of doing they might have
> time to
> work on other things the community can't deliver.
>
>
Let's see if we can convince them to do both!
Dick
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
