BLACKSTONE: Software Development Times Article

http://sdtimes.com/news/108/story7.htm Regards, Damon

Mmmmm.... Maybe we'll have distributed computing of CFML apps and CFCs across multiple CPUs on one of those supercomputers they construct by networking thousands of PC (Preferably MAcs). Anybody up for calculating pi to n+1 significant decimals?  Using CFML? Seriously, IMO, the gateway is one of the most significant (sleaper) features of Blackstone. Dick On Aug 16, 2004, at 4:27 PM, dcooper@macromedia.com dcooper@macromedia.com wrote: > http://sdtimes.com/news/108/story7.htm > >  Regards, > >  Damon

> Seriously, IMO, the gateway is one of the most significant (sleaper) > features of Blackstone. > It will probably be a sleeper feature in that not many people use it. The amount of JMS use in J2EE web applications is rather low. Why would CFML web applications need this kind of functionality more than Java developers? I have never used a message queue outside of an enterprise integration project. Anyway, if you remember one of the most hyped features of CFMX was cfimport, which "gives CFML developers access to thousands of JSP tab libraries." How many people are using cfimport for that purpose? It is clear to me that anything in CFML that requires knowledge of Java instantly lowers the potential market by a huge factor. For most folks the importance of CFMX's support for J2EE was simply the ability to deploy CFML applications on J2EE. If you ask me, the big new features will be Flash-based forms and the ability to easily create PDF files. Of course, BlueDragon's support for .NET could be this year's biggest CFML feature. -Matt

Huh?  The article is primarily about the Event Gateway architecture and doesn't even mention JMS once.  The Event Gateway stuff is about SMS and IM integration, listening on sockets, and asynchronous CFC calls.  All great stuff that I'd use a lot in my CF development (particularly async calls). Sam ---------------------------------------- Blog http://www.rewindlife.com TeamMM http://www.macromedia.com/go/team ---------------------------------------- ----- Excess quoted text cut - see Original Post for more -----

Matt I am with Sam here.  It's about the Event Gateway.  Presumably, anything that can create an event can initiate a CFC that need not be coupled with a browser (or anything, for that matter).  JMS is only one (of many) ways to create an event. I, personally, am very jazzed about this! Dick On Aug 16, 2004, at 7:15 PM, Samuel R. Neff wrote: ----- Excess quoted text cut - see Original Post for more -----

> Huh?  The article is primarily about the Event Gateway architecture and > doesn't even mention JMS once.  The Event Gateway stuff is about SMS and IM > integration, listening on sockets, and asynchronous CFC calls.  All great > stuff that I'd use a lot in my CF development (particularly async calls). Dumb question, but isn't that what JMS does? -- chris johnston www.fuzzylizard.com "For millions of years, mankind lived just like the animals and something happened which unleashed the power of our imagination, we learned to talk." Pink Floyd

It is a lot more that JMS! The article says that  you can set up a hot folder -- any time something is saved/changes in the folder it can fire a gateway event that triggers a CFC. ... no JMS there Dick On Aug 16, 2004, at 7:31 PM, Chris Johnston wrote: ----- Excess quoted text cut - see Original Post for more -----

Building Event Gateway based 1-way (push or pull) and 2-way interactive and session-aware Instant Messaging and cell phone SMS apps require only knowledge of CFML.  No Java knowledge is preferred or required.   Of course, the architecture is extensible, so if you need a Gateway to something and we don't include it, if you have Java skills, you can build your own for CFML developers to use. But I'd like to stress the point: no JMS or Java experience or knowledge is required to build these new types of apps. Just understand and get familiar with CFC's and you're all set.   Regards, Damon ----- Excess quoted text cut - see Original Post for more -----

This seems to be a very hot topic, so, I have to jump on this wagon too :) all right, in all earnestness, how about adding a feature to allow a developer to be able to distribute his/her app (eval copy, expires in 30 days etc. flexible, so he or she can set any exp. days of choice), now, would this investment justifiable, how about this?  implement it in a way that this feature does not come with the standard version while developer of interest can purchase it separately (as a component), I'm just thinking loud here. >http://sdtimes.com/news/108/story7.htm > >Regards, > >Damon

At 11:36 AM 8/17/2004, you wrote: >This seems to be a very hot topic, so, I have to jump on this wagon too :) >all right, in all earnestness, how about adding a feature to allow a developer to be able to distribute his/her app (eval copy, expires in 30 days etc. flexible, so he or she can set any exp. days of choice), now, would this investment justifiable, how about this?  implement it in a way that this feature does not come with the standard version while developer of interest can purchase it separately (as a component), I'm just thinking loud here. How about auto generation of 128-bit encrypted XML-based FuseDoc files? Or auto-connecting FuseBox .qry files? This would be awesome. -- Alex D & D Name: FuseLord Doom Handle: FuseKill

> The article says that  you can set up a hot folder -- any time > something is saved/changes in the folder it can fire a gateway event > that triggers a CFC. ... no JMS there > How is that new? You can do that today without an event gateway. -Matt

This is one of our sample Gateways provided for demonstration purposes and is provided with source code.  It will likely be useful for some folks, however.   When you give folks an open API, it sometimes surprising what they dream and come up with!   ----- Excess quoted text cut - see Original Post for more -----

If the source code is provided I think it is likely that more people will try to develop their own if the situation arises where they need something different. I know sometimes people just need a solid starting block, though I agree with Matt's skepticism. Adam On Tue, 17 Aug 2004 10:26:56 -0400, dcooper@macromedia.com dcooper@macromedia.com <dcooper@macromedia.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

> Of course, the architecture is extensible, so if you need a Gateway to > something and we don't include it, if you have Java skills, you can build > your own for CFML developers to use. > That is the key point, it requires Java skills if one of the built-in gateways doesn't do what you need. What is the likelihood of the built-in gateways doing everything you need? -Matt

A similar analogy might be the use vs creation of a JDBC driver:   You definitely want to use one, but you probably don't want to write one. The Gateways we provide will be well suited to their tasks, well tested, highly scalable and robust.  But we recognize it's a big world out there, and there may be new services, protocols or events (some maybe not yet invented) that you might want to talk with directly to enable your CFML apps to communicate with. In these cases, we left the door open for 3rd party vendors or advanced shops. Regards, Damon

If what you need to do is integrate with SMS, IM, Sockets, or any of the built-in gateways, then the chances it does what you need are really good. Sam ----- Excess quoted text cut - see Original Post for more -----

Matt, what exactly is your point... besides that the Event Gateway isn't that great of an idea?  Are you just trying to be contrary? ----- Excess quoted text cut - see Original Post for more -----

Matt Liotta wrote: ----- Excess quoted text cut - see Original Post for more ----- Small. But I think it is not unrealistic to expect the built-in gateways (plus a few extensions that will undoubtedly be released) will do the majority of what the majority of developers need. It will be a while before the average developer wants more then say IM, SMS, SNMP and maybe telnet and IRC. I can even see some demand for 'cool stuff' such as MUD gateways, but beyond that? Jochem

> A similar analogy might be the use vs creation of a JDBC driver: > > You definitely want to use one, but you probably don't want to write one. > I completely disagree. What possible reason would a CFML developer have for creating a JDBC driver? Every major database provides one, Macromedia provides a set, and there are various open source ones. In short, a CFML developer may pick an appropriate JDBC driver, but would never consider building one simply because all the needed drivers already exist. Compare this with an event gateway, which is still undefined, so the only possibly supplier will be Macromedia. Will Macromedia provide an event gateway for every need? I doubt it and you don't seem to be indicating that anyway. Thus, it is possible and likely that a CFML developer will want an event gateway that is not provided. -Matt

Analogies aside, the Event Gateway makes CF natively extensible and enables capabilities previously only available to organizations with access to extensive resources and specialized expertise.   The best part is you'll be able to build these apps (or add these capabilities to existing apps) literally in about 5 minutes with Blackstone. Hopefully we can once again make CF developers heroes in their companies and the envy of their peers.  :) We always welcome ideas, so if you have some for Gateways, we'd love to hear them.  I'm sure if there's demand, there will be enterprising 3rd parties anxious to meet the demand.  In fact, it's already happening :) It's going to be a good time to be a CFMX developer. Reards, Damon

dcooper@macromedia.com dcooper@macromedia.com wrote: > > We always welcome ideas, so if you have some for Gateways, we'd love to hear them. A SNMP trap gateway. Mainly receiving, so I can forward traps collected by the SNMP gateway through the SMS gateway to my mobile phone, but sending traps might be usefull for people who want to tie their CF servers into monitoring tools like HP OpenView. Jochem

Sweet!  Of course you do 2-way as well, so you could respond and DO something about it from your phone. >A SNMP trap gateway. Mainly receiving, so I can forward traps >collected by the SNMP gateway through the SMS gateway to my >mobile phone, but sending traps might be usefull for people who >want to tie their CF servers into monitoring tools like HP OpenView. > >Jochem

dcooper@macromedia.com dcooper@macromedia.com wrote: > Sweet!  Of course you do 2-way as well, so you could respond and DO something about it from your phone. Don't wake a sleeping BOFH ;-) Jochem

On Aug 17, 2004, at 8:08 AM, dcooper@macromedia.com dcooper@macromedia.com wrote: >  We always welcome ideas, so if you have some for Gateways, we'd love > to hear them.  I'm sure if there's demand, there will be enterprising > 3rd parties anxious to meet the demand.  In fact, it's already > happening :) > > If someone hasn't already done it, Email-driven CFCs: Trigger an event & invoke a CFC when email is received at a specific email account My first CF host provider (iTools, later Zanova) wrote a custom mailer (circa 1998) where: 1) When you defined an email account you could specify that a cfm be run when an email was received. 2) AIR, the cfm was passed variables containing all the email parts (as if a form had been submitted) This should be easy to implement using cfcs and the event gateway. I wrote a simple but effective (at the time) app to demo this feature Send an email to the designated account with a list of stock symbols in the body. my cfm would be triggered, retrieve stock quotes from wherever & send a return email So, if you were away from your computer, you could use your cell phone to send the email, and get back stock quotes But email-driven cfcs offer a lot of possibilities. They (Zanova) even had the ability to reboot a server with this facility Dick

> Compare this with an event gateway, which is still undefined, <cough> Speak for yourself. -- Tom Chiverton Advanced ColdFusion Programmer Tel: +44(0)1749 834997 email: tom.chiverton@bluefinger.com BlueFinger Limited Underwood Business Park Wookey Hole Road, WELLS. BA5 1AF Tel: +44 (0)1749 834900 Fax: +44 (0)1749 834901 web: www.bluefinger.com Company Reg No: 4209395 Registered Office: 2 Temple Back East, Temple Quay, BRISTOL. BS1 6EG. *** This E-mail contains confidential information for the addressee only. If you are not the intended recipient, please notify us immediately. You should not use, disclose, distribute or copy this communication if received in error. No binding contract will result from this e-mail until such time as a written document is signed on behalf of the company. BlueFinger Limited cannot accept responsibility for the completeness or accuracy of this message as it has been transmitted over public networks.***

It is always nice to see marketing speak on a technical mailing list. I never realized that the tiny startup I worked for back in 1998 who had an intern connect our CFML application to a message queue would be considered an organization with extensive resources and specialized expertise. -Matt ----- Excess quoted text cut - see Original Post for more -----

I would think you guys would be excited by this new functionality and what this will mean for you and your customers.  Am I missing something here?  

> Matt, what exactly is your point... besides that the Event Gateway > isn't that great of an idea?  Are you just trying to be contrary? > I thought I stated my point clearly; the event gateway doesn't seem that interesting of a feature for the greater CFML community especially when compared to the ability to create Flash-based forms or produce PDFs or even to deploy on .NET. Those features seem to have mass appeal. Macromedia is always pointing out how they have fixed resources meaning if they do one feature they can't do another. Hopefully, they won't spend too much time on a feature without mass appeal. -Matt

>>Hopefully, they won't spend too much time on a feature without mass appeal. We're definitely trying to spend our resources as wisely as possible.   We've held back talking about the Event Gateway and IM/SMS feature set during the early tours, etc for a number of reasons, but you'll be hearing much more about them.   Since we haven't shown or demoed the amazing Blackstone capabilities Event Gateways enable, I think you'll want to reserve judgment on their likely popularity.  Ben's teaser File Watcher demo ate one of the CFUG's (the only thing publicly shown about this feature set so far), definitely shouldn't be used to judge the likely appeal of this functionality.   The Blackstone feature set will without a doubt let CF developers think outside the web app box.  Web apps are great, but the world is increasingly wireless, mobile and instant.  Now and in the future, I believe the Event Gateway functionality and its extensibility will be important for customers to build apps that talk to anything, respond to anything, and can do virtually anything.  You can't have a grand vision like that without being open and extensible, and that's what we're doing. Lots of protocols discussed here, but we also want to think about the ones not yet invented, and proprietary ones as well.  Fr the Gateways we ship, I think we will be able to satisfy most needs.  For Gateways and message and event-based protocols we don't ship in the box, you don't have to wait for us to build them.   CF changed the world once before, spawning and inspiring ASP, JSP and others, and I think we're positioned to do it again.   Regards, Damon

On Aug 17, 2004, at 9:27 AM, dcooper@macromedia.com dcooper@macromedia.com wrote: > >  The Blackstone feature set will without a doubt let CF developers > think outside the web app box.  Web apps are great, but the world is > increasingly wireless, mobile and instant.  Now and in the future, I > believe the Event Gateway functionality and its extensibility will be > important for customers to build apps that talk to anything, respond > to anything, and can do virtually anything. ... and run anywhere... %^)> ----- Excess quoted text cut - see Original Post for more ----- Hear! Hear! Dick

If Macromedia provides us with the tools, to create such, I see no problem. Maybe it would become in like <cf_eventgateway             action="create"             event="network/io/db/memory/etc"             task="cfc"> And the use CFC's to handle the events. So the gateway only is a observer, and triggers cfc's to take action upon which event has been provided to the observer. Micha Schopman Software Engineer Modern Media, Databankweg 12 M, 3821 AL  Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380

> But I think it is not unrealistic to expect the built-in gateways > (plus a few extensions that will undoubtedly be released) will do > the majority of what the majority of developers need. It will be > a while before the average developer wants more then say IM, SMS, > SNMP and maybe telnet and IRC. I can even see some demand for > 'cool stuff' such as MUD gateways, but beyond that? > If you get IM and SMS, then SMTP, POP3, and IMAP will be asked for. If you get Telnet people will want SSH. What about FTP, SFTP, and SCP? Those seem useful. How many people will want NNTP? Let's not even talk about TCP, UDP, or ICMP. -Matt

That was the best acronym-ed post this list has ever seen.... Ray http://www.crystalvision.org At 11:40 AM 8/17/2004, you wrote: ----- Excess quoted text cut - see Original Post for more -----

At 11:46 AM 8/17/2004, you wrote: LMAO! TTFN, Alex ----- Excess quoted text cut - see Original Post for more -----

Matt Liotta wrote: ----- Excess quoted text cut - see Original Post for more ----- Well, if there really is such great demand for SCP a talented Java developer could probably make a killing developing a gateway for that. I wouldn't invest in his business though. Jochem

I'm sorry .. have I slipped on to some IBM discussion list?   All those acronyms - actually no I can't be a IBM list because many of the acronyms have more than 3 letters.  Must be a unix list.   How did this happen?  I thought we were a ColdFusion list.    No? Cheers Mike Kear Windsor, NSW, Australia AFP Webworks http://afpwebworks.com   _____ Sent: Wednesday, 18 August 2004 1:41 AM To: CF-Talk Subject: RE: BLACKSTONE: Software Development Times Article > But I think it is not unrealistic to expect the built-in gateways > (plus a few extensions that will undoubtedly be released) will do > the majority of what the majority of developers need. It will be > a while before the average developer wants more then say IM, SMS, > SNMP and maybe telnet and IRC. I can even see some demand for > 'cool stuff' such as MUD gateways, but beyond that? > If you get IM and SMS, then SMTP, POP3, and IMAP will be asked for. If you get Telnet people will want SSH. What about FTP, SFTP, and SCP? Those seem useful. How many people will want NNTP? Let's not even talk about TCP, UDP, or ICMP.

Wow, that company was able to do all that without event gateways. They must be an organization with extensive resources and specialized expertise. -Matt ----- Excess quoted text cut - see Original Post for more -----

On Aug 17, 2004, at 9:13 AM, Matt Liotta wrote: > Wow, that company was able to do all that without event gateways. They > must >  be an organization with extensive resources and specialized expertise. No, Matt, just a small very-talented staff. This was CF 3.x The person who conceived and implemented this is Jason Barney. He was CTO of the company & one of the most talented people I have encountered on the net. AIR, he was doing so much in those early days of (acceptance of) CF that Allaire flew him to Boston to pick his brain. Dick

Matt, I might be wrong here, but I don't think it's Macromedia's intention to make it COMPULSORY for you to use the new feature. I think you could take almost any aspect of ColdFusion and there would be people who would say "I have no idea why they bothered to put that in the product - we never use it. What a waste of time THAT was!"   So you wont use this feature.  Ok .. Don't.   But I'll bet you'll find plenty that will make your life better/simpler/more efficient.   Every version of CF so far as done that for us, and I reckon most of the others on this list too. Cheers Mike Kear Windsor, NSW, Australia AFP Webworks http://afpwebworks.com <http://afpwebworks.com/>; (Organisation with limited resources but specialised expertise.)   _____ Sent: Wednesday, 18 August 2004 2:14 AM To: CF-Talk Subject: RE: BLACKSTONE: Software Development Times Article Wow, that company was able to do all that without event gateways. They must be an organization with extensive resources and specialized expertise. -Matt

> Matt, I might be wrong here, but I don't think it's Macromedia's intention > to make it COMPULSORY for you to use the new feature. > I don't think anyone even implied that. > I think you could take almost any aspect of ColdFusion and there would be > people who would say "I have no idea why they bothered to put that in the > product - we never use it. What a waste of time THAT was!" > Sure, but the question is always how many. If most people feel that way then it was a waste of time. If most people don't feel that way then it likely wasn't a waste of time. My assertion is that features like Flash-based forms have much wider appeal. > So you wont use this feature.  Ok .. Don't.   But I'll bet you'll find > plenty that will make your life better/simpler/more efficient.   Every > version of CF so far as done that for us, and I reckon most of the others > on > this list too. > I didn't state I wouldn't use this feature. I simply responded to the notion that is an important feature. I don't think it is. -Matt

Fair enough. ----- Excess quoted text cut - see Original Post for more -----

On Aug 17, 2004, at 10:04 AM, Matt Liotta wrote: >  I didn't state I wouldn't use this feature. I simply responded to the > notion >  that is an important feature. I don't think it is. > Matt My opinion is just the opposite. the Event Gateway decouples a cfmx app from the browser -- that means: 1) you can run a cf app anywhere that meets the requirements 2) The CF developer will be able to apply the CF advantages to a much, much broader range of applications (web and non-web) 3) There are a lot of non-browser things you need to do when setting up and running an application (define db tables, prime db with initial data, backup databases, backup the site, dump/check-out portions of the data for off-line processing, etc).  You could kluge together a solution using CFMs and a browser, but many of these repetitive tasks don't need (or are hampered by) a browser interface.  Better to have a decoupled language with the power of CFML CFML isn't perfect (yet) but it is superior to any scripting (and most programming) languages that I have used (and I have used a few).  I would like to see CFML become the lingua franca of scripting languages. Now, where can I get a JVM for my iPod? Dick

At 01:31 PM 8/17/2004, you wrote: CF Isn't perfect, but BlueDragon is. Instead of investing in gateways and silly things like flash-based forms, New Atlanta included the <CFDRYCLEAN> tag. This is the first Web application server with a truly "mass appeal" feature: pickup your dry cleaning. You still have to drop it off, but one call to the <CFDRYCLEAN> tag, and there will be knock at your door...BAM.....cleaned, pressed and delivered! Look for other new "mass appeal" features to be released in "Feature Packs". Some of these will include: <CFOILCHANGE> <CFCARWASH> <CFBRUSHTEETH> and the most anticipated feature to date: <CFEZDIVORCE> Stay tuned... -- Alex >CFML isn't perfect (yet) but it is superior to any scripting (and most >programming) languages that I have used (and I have used a few).  I >would like to see CFML become the lingua franca of scripting languages. > >Now, where can I get a JVM for my iPod? > >Dick

I think you left off my favorite: <CFWRITEMYAPPLICATIONFORME> -joe

At 03:53 PM 8/17/2004, Joe Rinehart wrote: >I think you left off my favorite: > ><CFWRITEMYAPPLICATIONFORME> I start every program with: <CFSetErrorsOff> <CFDoWhatIMeant> T

Matt Liotta wrote: > > Sure, but the question is always how many. If most people feel that > way then > it was a waste of time. If most people don't feel that way then it likely > wasn't a waste of time. My assertion is that features like Flash-based > forms > have much wider appeal. Let's find out... I just created a new poll on my blog: http://www.petefreitag.com/ (on the bottom of the left menu). ______________________________________ Pete Freitag http://www.cfdev.com/ Author of the CFMX Developers Cookbook http://www.petefreitag.com/bookshelf/

> the Event Gateway decouples a cfmx app from the browser -- that means: > It does no such thing since a CFML application was never coupled with the browser in the first place. > 1) you can run a cf app anywhere that meets the requirements > You can do that now. > 2) The CF developer will be able to apply the CF advantages to a much, > much broader range of applications (web and non-web) > You can do that now. ----- Excess quoted text cut - see Original Post for more ----- There are a ton of solutions commercial, free, and open source that take care of deployment and administration issues already. All of these are better suited to the task than CFML and will continue to be even if with the addition of an event gateway. The problem in this case was never that CFML was hampered by a browser interface, but that CFML is the wrong tool for the job in the first place. > CFML isn't perfect (yet) but it is superior to any scripting (and most > programming) languages that I have used (and I have used a few).  I > would like to see CFML become the lingua franca of scripting languages. > I disagree. CFML is well suited for what it was designed for. In fact, I would go as far as to say that CFML is the best scripting language available for web-based projects. However, don't confuse how wonderful CFML is in the web world with its potential in other application domains. Each tool has its place and it is important to understand where CFML fits in. -Matt

I tend to agree with this perspective. CFML is so good at what it does, when we as web developers are tasked with something completely different, we tend to want to bend and shape CF in order to perform tasks it is not particularly well suited to do. It used to be that this was restricted more to the individual developer, but it seems more and more that new, official versions of CF are being packaged with these "tweaks", and presented as core functionality within the language.  It's not always better to do more, if you can't do more, better. Brian   <snip>   I disagree. CFML is well suited for what it was designed for. In fact, I   would go as far as to say that CFML is the best scripting language available   for web-based projects. However, don't confuse how wonderful CFML is in the   web world with its potential in other application domains. Each tool has its   place and it is important to understand where CFML fits in.   -Matt

Now that was some funny shit.  LOL -Mike ----- Excess quoted text cut - see Original Post for more -----

The gist of the below response is fairly common with your emails, Matt. But CFML is actually only a developer time language, at runtime we are using Java. Maybe it can be suited for more.  I wouldn't worry so much as folks try these things out, you never know what creativity and thinking outside the box will gain everyone, especially the creative thinker themselves. - Calvin Subj:  RE: BLACKSTONE: Software Development Times Article > the Event Gateway decouples a cfmx app from the browser -- that means: > It does no such thing since a CFML application was never coupled with the browser in the first place. > 1) you can run a cf app anywhere that meets the requirements > You can do that now. > 2) The CF developer will be able to apply the CF advantages to a much, > much broader range of applications (web and non-web) > You can do that now. ----- Excess quoted text cut - see Original Post for more ----- There are a ton of solutions commercial, free, and open source that take care of deployment and administration issues already. All of these are better suited to the task than CFML and will continue to be even if with the addition of an event gateway. The problem in this case was never that CFML was hampered by a browser interface, but that CFML is the wrong tool for the job in the first place. > CFML isn't perfect (yet) but it is superior to any scripting (and most > programming) languages that I have used (and I have used a few).  I > would like to see CFML become the lingua franca of scripting languages. > I disagree. CFML is well suited for what it was designed for. In fact, I would go as far as to say that CFML is the best scripting language available for web-based projects. However, don't confuse how wonderful CFML is in the web world with its potential in other application domains. Each tool has its place and it is important to understand where CFML fits in. -Matt

In regards to the event gateway feature I respectfully disagree with you...I think it will be quite useful for intermediate to advanced CF folk. Time will tell. How bout we move on folks... Stace ________________________________________ Sent: Tuesday, August 17, 2004 1:42 PM To: CF-Talk Subject: RE: BLACKSTONE: Software Development Times Article > the Event Gateway decouples a cfmx app from the browser -- that means: > It does no such thing since a CFML application was never coupled with the browser in the first place. > 1) you can run a cf app anywhere that meets the requirements > You can do that now. > 2) The CF developer will be able to apply the CF advantages to a much, > much broader range of applications (web and non-web) > You can do that now. ----- Excess quoted text cut - see Original Post for more ----- There are a ton of solutions commercial, free, and open source that take care of deployment and administration issues already. All of these are better suited to the task than CFML and will continue to be even if with the addition of an event gateway. The problem in this case was never that CFML was hampered by a browser interface, but that CFML is the wrong tool for the job in the first place. > CFML isn't perfect (yet) but it is superior to any scripting (and most > programming) languages that I have used (and I have used a few).  I > would like to see CFML become the lingua franca of scripting languages. > I disagree. CFML is well suited for what it was designed for. In fact, I would go as far as to say that CFML is the best scripting language available for web-based projects. However, don't confuse how wonderful CFML is in the web world with its potential in other application domains. Each tool has its place and it is important to understand where CFML fits in. -Matt ________________________________________

I personally feel that features like event gateway, once we 'understand' its details will have features to integrate 3rd party vendors. I am curious how Sean Cornfield implemented it against Oracle Financial, since we have a similar situation. I can see a given gateway being 'built' against maybe an OLAP or Content Management sysytem. Patrick Whittingham In regards to the event gateway feature I respectfully disagree with you...I think it will be quite useful for intermediate to advanced CF folk. Time will tell. How bout we move on folks... Stace ________________________________________ Sent: Tuesday, August 17, 2004 1:42 PM To: CF-Talk Subject: RE: BLACKSTONE: Software Development Times Article > the Event Gateway decouples a cfmx app from the browser -- that means: > It does no such thing since a CFML application was never coupled with the browser in the first place. > 1) you can run a cf app anywhere that meets the requirements > You can do that now. > 2) The CF developer will be able to apply the CF advantages to a much, > much broader range of applications (web and non-web) > You can do that now. ----- Excess quoted text cut - see Original Post for more ----- There are a ton of solutions commercial, free, and open source that take care of deployment and administration issues already. All of these are better suited to the task than CFML and will continue to be even if with the addition of an event gateway. The problem in this case was never that CFML was hampered by a browser interface, but that CFML is the wrong tool for the job in the first place. > CFML isn't perfect (yet) but it is superior to any scripting (and most > programming) languages that I have used (and I have used a few).  I > would like to see CFML become the lingua franca of scripting languages. > I disagree. CFML is well suited for what it was designed for. In fact, I would go as far as to say that CFML is the best scripting language available for web-based projects. However, don't confuse how wonderful CFML is in the web world with its potential in other application domains. Each tool has its place and it is important to understand where CFML fits in. -Matt ________________________________________   _____  

> I personally feel that features like event gateway, once we 'understand' its details will have features to integrate 3rd party vendors. I am curious how > Sean Cornfield implemented it against Oracle Financial, since we have a similar situation. I can see a given gateway being 'built' against maybe an OLAP or > Content Management sysytem. I'd already built a standard CF app that took XML files and imported them into Oracle Applications via the database. The event gateway has allowed me to receive XML messages asynchronously and use the same code to process them as I was already using for the XML files. JMS is much more reliable than shuffling files around and lets me process data in real time instead of using a scheduled task to poll the FTP server for new data files... -- Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

On Aug 17, 2004, at 5:02 PM, Sean Corfield wrote: ----- Excess quoted text cut - see Original Post for more ----- So, using mostly existing CF contrusts, you are able to improve reliability and performance of the individual app and reduce overall impact (firing a scheduled task to poll for work) on the entire CF system. That's pretty significant! Dick

----- Excess quoted text cut - see Original Post for more ----- What about the event gateway allowed you to do this exactly? I can receive XML message asynchronously now. I can imagine that the event gateway allows you to do this more elegantly than current solutions. However, the only missing piece currently is Java invocation of CFCs. It almost seems like Macromedia went to far since the event gateway likely constrains people where as Java invocation of CFCs does not. -Matt

On Aug 17, 2004, at 7:03 PM, Matt Liotta wrote: ----- Excess quoted text cut - see Original Post for more ----- They made it easy! Dick

> However, the only > missing piece currently is Java invocation of CFCs. See Ben Forta's tour report: http://www.macromedia.com/devnet/mx/coldfusion/articles/blackstone.html In particular: "Lots of Other Goodies Big and exciting marquee features grab the limelight, but there is a lot more to Blackstone too. Some of the other goodies include: ...     * Access to CFC code from Java ..." So Blackstone will include the raw access that you mention. The question is then whether the event gateway adds value on top of that. I'll argue it does. Blackstone will ship with a number of out-of-the-box gateways that connect to a number of protocols - meaning ColdFusion developers don't need to write them. That in itself is a win. Blackstone also provides an easy-to-use basic framework for such gateways to run inside, wired into the CF Admin. Ease of management is another win. -- Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

matt, does anything make u happy? my god man what can we do 2 put some sunshine up yer bum? Reply-To: cf-talk@houseoffusion.com Date:  Tue, 17 Aug 2004 22:03:56 -0400 ----- Excess quoted text cut - see Original Post for more -----

Matt, don't you realize that the event gateway IS external Java invocation of CFCs?  I remember you complaining about not being able to to this without really digging really deep and that it really wasn't recommened due to its fragile and tricky nature. Isn't nice that MM has provided a public, documented and fully supported API for interacting with CFMX via extenal Java code? Sure, the event gateway is not the most wiz-bang feature in store, but decoupling CFMX from the HTTP protocol (not the browser) and making that lower level interaction simple and accessible is a very important change. Think about this... don't like the way CFMX handles webservices? Thinks its buggy and a pain to use?  Just don't want to use Axis because you have a better idea? Write your own event gateway for webservices and that utilizes some other SOAP engine.  Want to implement SOAP via SMTP which CF doesn't really do?  Write your own gateway. Come on Matt.  Java's great, but why bother with it if you don't have to... especially if you can do it easier in CF? ----- Excess quoted text cut - see Original Post for more -----

> Matt, don't you realize that the event gateway IS external Java > invocation of CFCs?  I remember you complaining about not being able > to to this without really digging really deep and that it really > wasn't recommened due to its fragile and tricky nature. Isn't nice > that MM has provided a public, documented and fully supported API for > interacting with CFMX via extenal Java code? > I don't believe the event gateway and Java invocation of CFCs is the same thing. There should be an easy way to call CFCs from Java and my understanding is that Blackstone will have it. The event gateway it seems will be at a higher level constraining you to a framework Macromedia designed. > Sure, the event gateway is not the most wiz-bang feature in store, but > decoupling CFMX from the HTTP protocol (not the browser) and making > that lower level interaction simple and accessible is a very important > change. > If you have Java invocation of CFCs then you don't have to be tied to the HTTP protocol anyway. Again, the event gateway is not required for all the use cases people keep mentioning. > Think about this... don't like the way CFMX handles webservices? > Thinks its buggy and a pain to use?  Just don't want to use Axis > because you have a better idea? Write your own event gateway for > webservices and that utilizes some other SOAP engine.  Want to > implement SOAP via SMTP which CF doesn't really do?  Write your own > gateway. > Again, with Java invocation of CFCs you could do just that. What about the event gateway makes it better? > Come on Matt.  Java's great, but why bother with it if you don't have > to... especially if you can do it easier in CF? > Again, if the built-in event gateways don't do what you want you still need to use Java to build them, so that isn't really an argument. -Matt

> Blackstone will ship with a number of out-of-the-box gateways that > connect to a number of protocols - meaning ColdFusion developers don't > need to write them. That in itself is a win. > Agreed, but Macromedia could have supplied protocol handlers without building an event gateway. Instead, they went and built a framework that constrains what an event gateway is and can do. That could be a really good thing or it could be a really bad thing. Time will tell, but so far frameworks have always been done better in the community. > Blackstone also provides an easy-to-use basic framework for such > gateways to run inside, wired into the CF Admin. Ease of management is > another win. > What is managed exactly? If it is anything like the web service "management" you find now then no thanks. -Matt

is the underlying factor here some problem with how BD wont be able to piggyback the event gateway or use it or steal it? must be something like this, or else i dont think matt's panties would be in a bunch like this...they only tend to get into this sorta snag when something like this is happening... ----- Excess quoted text cut - see Original Post for more -----

I don't know what to do with you Tony. You keep posting comments with no basis in facts that don't make much sense anyway. I'd really like to avoid addressing them or falling prey to my desire to respond negatively. Is that what you want? Is there some point to your comments? For the rest of you reading this, I have no financial interest in the success or failure of BlueDragon. Although, I would like to see them succeed. I don't know whether New Atlanta will implement the event gateway. I don't know whether they can. I certainly think they should implement it if for no other reason then to be compatible with ColdFusion. We all want that right? Personally, if I were to guess which functionality would be hard to implement in BlueDragon I wouldn't guess something like the event gateway. I would guess something that produces Flash on the fly. -Matt ----- Excess quoted text cut - see Original Post for more -----

Personally, the moment BlueDragon came out I thought.. "those guys actually give us what the community always wanted". BlueDragon just filled up that spot which has always been on the request list of many developers. And also personally, I don't think I will ever use Flash forms, or auto-generated forms by ColdFusion, you always have to do a lot of work to let it fit into the application. The chances that I use the event gateway are way much higher, but as someone already said, it depends on the model and since we haven't seen any model or code it is hard to discuss about it or to form an opinion about it. Personally, for me the selling points in Blackstone are the reporting features, the cfdocument tag, and the compiled deployment of files. If you are a basic ColdFusion user, flashy forms are nice, but for me, as I use and code in javascript extensivily, Flash forms are unsufficient and cause to much overhead in the bigger picture. I now this is a feature Macromedia has to push, because of the rich internet model strategy combined with Flex etc., but I am kinda resistant to those niché things which seem to cost me more time than they promise. "Customer A; I don't like the blue spot" "Customer B; I miss this and this functionality" .. .. I guess I ended up starting FlashMX, developing the missing parts, and still it doesn't react or isn't as fast as ordinary markup with javascript. :) Micha Schopman Software Engineer Modern Media, Databankweg 12 M, 3821 AL  Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380

you know what man, i dont want, wait a minute, YOU CANT DO ANYTHING WITH ME, you dont have that option, friend, sorry. now, mike d, he could throw him off the list, sure... im not here to get into a pissing match with you matt, i just tend to be the voice of the soft spoken crowd. the crowd that is sick of your sentiments, sick of your cynicism and just generally sick of your pessimistic arrogance... matt, i respect your intelligence, i respect your message, you are way off the scales on the iq chart im sure, but....your delivery sucks. if your personality was half of what your intelligence was, man, im sure you could be president.  i hope this doesnt offend you, its not intended to do so, this list isnt the forum for this, and i dont have the time for it, but please, dont take offense, learn a lesson in people skills, it will GET YOU VERY FAR!!!!!!!!!! tony. ----- Excess quoted text cut - see Original Post for more -----

I particularly like the feature in Blackstone of being able to incorporate PGP encryption for better security of personal information collected on e-commerce applications, but the document and reporting functionality is awesome as well. Event management is probably a feature set that I would rarely use, but I guess it does not hurt anything that it is available if wanted or needed. As for BD, I think the perception is that MM is mainly targeting the high end user, while the low end and middle is where most of us operate.  For this area BD fills a vacant spot.. It does have most of the functionality we use from day to day, but it is not the end-all Of course, we all realize that not all web sites are requiring rich media, flash glitz, etc, and, in fact are much simpler in concept and layout.  Of course, CSS is being more widely used, and that alone helps a lot with load times, and site appearance without having to copy and pase duplicate code all over the place. CSS makes it easier to completely change the appearance of a site making it very useful in development of multiople sites whose layout may be similar but still have an individually desinged look and feel. Many of the higher priority items which are so often overlooked is the ease of use, user friendly navigation throughout the site.  When every site you visit have a different concept of navigation, use of popups, popunders, etc, seems to turn a lot of visitors off and shortens both their visit time but their visit frequency. I personally have much admiraton for the develoeprs who do the sites for music and artistic sites, because just like with their live performances flashy and glitzy is what it is all about.   On the other hand, many web sites, just by their nature can be actually harmed by the addition of complicated flash, and weird navigation schemes, and even more admiration must be given tothe developer who can tell the difference and use it in theor approach to marketing their skills. ====================================== Our Anti-spam solution works!! http://www.clickdoug.com/mailfilter.cfm For hosting solutions http://www.clickdoug.com http://www.forta.com/cf/isp/isp.cfm?isp_id=1069 ======================================   Personally, the moment BlueDragon came out I thought.. "those guys actually give us what the community always wanted". BlueDragon just filled up that spot which has always been on the request list of many developers.

I've been following this thread and I wanted to share my thoughts... I've been developing for many years now and I'm a firm believer in using the right technology for the right job. Arguing about whether to use a Macromedia supplied tag or to write something in Java is a personal choice. If the Macromedia supplied tags will do the job and do it well, then that maybe that's the best route. If more advanced functionality is needed then then maybe Java, or other appropriate technology. Choosing the right technology depends on a number of factors, including available resources, money, time, skills,etc. Macromedia, New Atlanta, etc are in business to make money. The best way to do that is to sell products to as many people as possible. To do that these products have to appeal to as many people as possible. I agree with Doug. Macromedia, by building in higher level, easier to use features, they appeal to more high-end users. It should also be bore in mind that one of the "key features" of Blackstone is that there will be something for everyone. From the advanced developer who's been using ColdFusion or Java for years, down to the beginner who's just started writing applications. Personally I'm looking forward to trying Blackstone out. There's so many things I'd like to try, and from the very brief details around I can think of several uses for the features that have been mentioned. As to whether they will fit in with my applications, that will be seen when the full documentation or product is ready for testing. Gavin I particularly like the feature in Blackstone of being able to incorporate PGP encryption for better security of personal information collected on e-commerce applications, but the document and reporting functionality is awesome as well. Event management is probably a feature set that I would rarely use, but I guess it does not hurt anything that it is available if wanted or needed. As for BD, I think the perception is that MM is mainly targeting the high end user, while the low end and middle is where most of us operate.  For this area BD fills a vacant spot.. It does have most of the functionality we use from day to day, but it is not the end-all Of course, we all realize that not all web sites are requiring rich media, flash glitz, etc, and, in fact are much simpler in concept and layout.  Of course, CSS is being more widely used, and that alone helps a lot with load times, and site appearance without having to copy and pase duplicate code all over the place. CSS makes it easier to completely change the appearance of a site making it very useful in development of multiople sites whose layout may be similar but still have an individually desinged look and feel. Many of the higher priority items which are so often overlooked is the ease of use, user friendly navigation throughout the site.  When every site you visit have a different concept of navigation, use of popups, popunders, etc, seems to turn a lot of visitors off and shortens both their visit time but their visit frequency. I personally have much admiraton for the develoeprs who do the sites for music and artistic sites, because just like with their live performances flashy and glitzy is what it is all about.   On the other hand, many web sites, just by their nature can be actually harmed by the addition of complicated flash, and weird navigation schemes, and even more admiration must be given tothe developer who can tell the difference and use it in theor approach to marketing their skills. ====================================== Our Anti-spam solution works!! http://www.clickdoug.com/mailfilter.cfm For hosting solutions http://www.clickdoug.com http://www.forta.com/cf/isp/isp.cfm?isp_id=1069 ======================================   Personally, the moment BlueDragon came out I thought.. "those guys actually give us what the community always wanted". BlueDragon just filled up that spot which has always been on the request list of many developers.   _____  

----- Excess quoted text cut - see Original Post for more ----- Like all things CF, it's more accessible to people who aren't Java experts. After all, a structure is just a Java object. So what makes CF structures any better than using the underlying Java object (which is also available to us)? As to the cf-admin -- I haven't needed webservices for anything I've worked on yet, but as a rule, I prefer things to not be in the CF-Admin... If I could get DSN-less connections with CFMX, I'd be all over it. Frameworks designed better in the community: yes and no. Although I haven't used cflogin yet, I'm not about to rewrite the "application framework". s. isaac dealey     954.927.5117 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.sys-con.com/story/?storyid=44477&DE=1 http://www.sys-con.com/story/?storyid=45569&DE=1 http://www.fusiontap.com

> CF-Admin... If I could get DSN-less connections with CFMX, I'd be all > over it. Umm, you can, with the service factory java objects... -- Tom Chiverton Advanced ColdFusion Programmer Tel: +44(0)1749 834997 email: tom.chiverton@bluefinger.com BlueFinger Limited Underwood Business Park Wookey Hole Road, WELLS. BA5 1AF Tel: +44 (0)1749 834900 Fax: +44 (0)1749 834901 web: www.bluefinger.com Company Reg No: 4209395 Registered Office: 2 Temple Back East, Temple Quay, BRISTOL. BS1 6EG. *** This E-mail contains confidential information for the addressee only. If you are not the intended recipient, please notify us immediately. You should not use, disclose, distribute or copy this communication if received in error. No binding contract will result from this e-mail until such time as a written document is signed on behalf of the company. BlueFinger Limited cannot accept responsibility for the completeness or accuracy of this message as it has been transmitted over public networks.***

----- Excess quoted text cut - see Original Post for more ----- And with that... Tony single handedly silenced the list.  LOL

At 09:56 AM 8/18/2004, you wrote: ----- Excess quoted text cut - see Original Post for more ----- Nope. If the gateway doesn't support FuseBox 4.5 circuits and the FLiP process (not to mention .qry and .dsp files), then MACR should go with Mach-II listeners. Mach-II is really the best choice to build the forthcoming remote Java --> CFC invocation event-based gateway, by far. -- True

I'm more silenced at the notion of Tony representing the "soft spoken"  :) (but while there is a short silence, I'm going to throw in a soft spoken request that this thread move to community?) Alexander Sherwood wrote: ----- Excess quoted text cut - see Original Post for more -----

What are you talking about? If you're being serious, this doesn't make any sense at all. If you're joking, it's not funny. At 09:56 AM 8/18/2004, you wrote: ----- Excess quoted text cut - see Original Post for more ----- Nope. If the gateway doesn't support FuseBox 4.5 circuits and the FLiP process (not to mention .qry and .dsp files), then MACR should go with Mach-II listeners. Mach-II is really the best choice to build the forthcoming remote Java --> CFC invocation event-based gateway, by far. -- True________________________________

At 10:36 AM 8/18/2004, you wrote: >What are you talking about? If you're being serious, this doesn't make >any sense at all. If you're joking, it's not funny. I'm serious. I just ported the Mach-II framework to a nice, compact 12K executable for my Commodore-64. Now I can connect my 64 (and my old Commodore PET, soon) to my Pentium box via the gateway. Decoupling CFMX from the jaws of HTTP has opended new doors for legacy integration. And FB4 makes this possible. -- Alex ----- Excess quoted text cut - see Original Post for more -----

> If the gateway doesn't support FuseBox 4.5 circuits and the FLiP process (not to mention .qry and .dsp files), then MACR should go with Mach-II listeners. Funny you should mention that - I'm currently building a proof of concept integration between the event gateway and Fusebox 4... See you at Fusebox 2004? http://www.cfconf.org/fusebox2004/ -- Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

> If the gateway doesn't support FuseBox 4.5 circuits and > the FLiP process (not to mention .qry and .dsp files), > then MACR should go with Mach-II listeners. > Mach-II is really the best choice to build the forthcoming > remote Java --> CFC invocation event-based gateway, by > far. Ummm... no... Macromedia should do nothing to support any framework whether it's FB, Mach-II, the onTap framework or anything else. They should build ColdFusion to support (gasp!) ColdFusion and let us figure out how to translate that into something we can use in our independent frameworks. The "best choice to build the forthcoming remote Java --> CFC invocation event-based gateway" by far is Java and CFC's. I'm pretty sure Macromedia sees it this way as well. s. isaac dealey     954.927.5117 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.sys-con.com/story/?storyid=44477&DE=1 http://www.sys-con.com/story/?storyid=45569&DE=1 http://www.fusiontap.com

> Like all things CF, it's more accessible to people who aren't Java > experts. > Writing an event gateway requires knowledge of Java therefore yours is not a valid argument. > After all, a structure is just a Java object. So what makes CF > structures any better than using the underlying Java object (which is > also available to us)? > You are using the underlying Java object. > Frameworks designed better in the community: yes and no. Although I > haven't used cflogin yet, I'm not about to rewrite the "application > framework". > I bet more people are using their own authentication schemes than cflogin. -Matt

> > Like all things CF, it's more accessible to people who aren't Java > > experts. > > > Writing an event gateway requires knowledge of Java therefore yours is not > a valid argument. Declaring that it's not a valid argument does not make it so. As many people have already stated, there will be several built in gateways. ColdFusion developers will be able to start using these from day one with no knowledge of Java. I've only had the past week or two to think of ways to utilize gateways. The gateways that have already been announced sound like they will suffice for the uses I've been able to come up with. However, I'm sure that, as new possibilities occur to me, I may find I need other gateways. At which point, I'm sure I'll be able to download or purchase gateways from third parties. If all else fails, I can hire a Java programmer to write the gateway and then program to it from within ColdFusion. None of these options require any knowledge of Java on my part. Granted, the third option, hiring a Java programmer, doesn't offer ColdFusion developers much more than what is capable today. Nevertheless, the gateway architecture will provide a de facto standard for integrating gateways with ColdFusion. I think that alone is a good thing because it gives developers, writers and teachers something to focus on and simplifies the language for discussing gateways and their use from within ColdFusion. -ben

> Writing an event gateway requires knowledge of Java therefore yours is not a > valid argument. True but using one of the out-of-the-box gateways does not nor will using any 3rd party gateways that people write. The end result will be access to a large number of protocols with no knowledge of Java required - for example, my JMS gateway would allow any CF developer to write a pure CF app that processed JMS XML messages with no knowledge of Java at all. > I bet more people are using their own authentication schemes than cflogin. And I bet they're writing them all in pure CF - what's your point with that analogy? -- Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

On Aug 20, 2004, at 8:59 AM, Sean Corfield wrote: ----- Excess quoted text cut - see Original Post for more ----- Will the OOTB gateways be released as source?  If it has not been decided, I would lobby in favor of making then 0pen-source examples of how to implement an event gateway. JMS, in particular is dependent on the implementation of the specific JMS provider.  (JBoss, JRun, IBM, etc all have different interfaces).   Many Blackstone users will likely run on JRun, and use the built-in JMS provider.  But, I cannot find any workable JRun JMS examples. TIA Dick

> JMS, in particular is dependent on the implementation of the specific > JMS provider.  (JBoss, JRun, IBM, etc all have different interfaces). That isn't really true: if you program against the javax.jms specification you will be able to write portable JMS consumer / publisher code. > But, I cannot find any workable JRun JMS examples. The examples in the docs are fragments. I used those examples with only small additions to write code that works on JRun and Fiorano MQ without any changes (only the config file changes, specifying the vendor-specific class names used for context factories etc). -- Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

On Aug 20, 2004, at 3:16 PM, Sean Corfield wrote: ----- Excess quoted text cut - see Original Post for more ----- I have looked at that and a lot of other JMS-related articles, from what I have been able to determine the specifications are pretty specific on the message format and interfaces to the provider.  Other than that, it is left to the implementor.  And, it appears that each implementation has its own nuances and extra features (that provide advantage over the competition). In a way, it is analogous to the SQL specification(s) and implementations -- not all db implementations have transactions, subselects, autonumbering, etc. and/or the soecify these in different ways (identity, auto_number, etc). For someone new to the territory it is difficult to determine where the "specification" leaves off and the vendor-specific implementation begins. Examples of my current frustration: 1) I can't make anything work on JRUn JMS 2) OpenJMS has some very nice, working examples, with source (and a lot of proprietary jars).  These run fine on OpenJMS but I have been unsuccessful porting any of them to JRun 3) There is a very nice Open-Source JMS Browse/Administrator that works with ActiveMQ, JBossMQ, and Websphere MQ -- but according to the forums, others, more expert than I have had little success running on other JMS systems (I tried on OpenJMS without success) So, what you stated above ("if you program against the javax.jms spec") you will likely have compatibility -- but it seems that very few people do! To illustrate this: lifted from the livedocs JRun JMS code fragment: private String providerurl = new String("localhost:2918"); lifted from an OpenJMS code fragment: int jndiPort = 1099; String jndiHost = "localhost"; I realize that these are examples. meant to illustrate the code, rather than getting params from a config file -- but a newbie usually starts with examples like these and they have built-in incompatibilities and bad coding practices  -- and, I guess the newbie is supposed to intuitively know this. I know that OpenJMS works -- I am running it. I assume that JRun JMS works, but cannot find any program that will run on JRunJMS (Macromedia & Google searches Plus my own feeble attempts to complete the code fragment or port OpenJMS examples.) My frustration, was the reason that I wrote the above paragraph in the context of lobbying for source to the Macromedia-supplied event gateway examples. ----- Excess quoted text cut - see Original Post for more ----- Yeah, but you know what you're doing :). Dick

> In a way, it is analogous to the SQL specification(s) and > implementations In other words "Yes, you can write portable JMS code if you know what you're doing"... > 1) I can't make anything work on JRUn JMS I've sent you corrections to your JMS example code off-list. As I've said, I have code that runs unchanged on both JRun and Fiorano MQ (you just change the provider URL - which is the host and port combination). > 2) OpenJMS has some very nice, working examples, with source (and a lot > of proprietary jars).  These run fine on OpenJMS but I have been > unsuccessful porting any of them to JRun I'm sorry that the examples provided with OpenJMS are so proprietary that they only run on OpenJMS... > So, what you stated above ("if you program against the javax.jms spec") > you will likely have compatibility -- but it seems that very few people > do! You need to bear in mind that writing Java to manipulate JMS is not exactly a novice task... ----- Excess quoted text cut - see Original Post for more ----- A provider URL is a host / port pair so I'd read these as pretty much equivalent - and an indication that OpenJMS just uses a different default port (not surprising - we configure Fiorano MQ to use a variety of different ports). > I realize that these are examples. meant to illustrate the code, rather > than getting params from a config file -- but a newbie usually starts > with examples like these and they have built-in incompatibilities and > bad coding practices  -- and, I guess the newbie is supposed to > intuitively know this. That's the problem with trying to start with someone else's example code instead of reading and understanding all the docs and writing the code yourself from scratch... :) Seriously tho' an example is no use unless you understand what the examples are trying to illustrate (in my experience, most examples are really only trying to illustrate something that is explained in the docs - rather than trying to be a replacement for the docs). > Yeah, but you know what you're doing :). If it's any consolation, I've had to spend a lot of time reading the javax.jms API documentation... -- Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

> Declaring that it's not a valid argument does not make it so. As many > people > have already stated, there will be several built in gateways. ColdFusion > developers will be able to start using these from day one with no > knowledge > of Java. > You are missing the context of the thread though. The original statement was as follows. > Think about this... don't like the way CFMX handles webservices? > Thinks its buggy and a pain to use?  Just don't want to use Axis > because you have a better idea? Write your own event gateway for > webservices and that utilizes some other SOAP engine.  Want to > implement SOAP via SMTP which CF doesn't really do?  Write your own > gateway. > As you can see, the poster suggested that a new gateway could be written, so yes it does indeed require knowledge of Java. Since this particular use can is not made easier by CF and requires knowledge of Java then the argument that CF makes it easier is not valid. -Matt

> You are missing the context of the thread though. Maybe I am. I don't think so, but it's always possible. :) This thread has been very long, and, as most mailing list conversations go, it's covered quite a bit of territory. > The original statement was as follows. Which itself was a reply to previous message. > As you can see, the poster suggested that a new gateway could be written, > so yes it does indeed require knowledge of Java. Since this particular use > can is not made easier by CF and requires knowledge of Java then the > argument that CF makes it easier is not valid. I disagree. I'm sure ColdFusion (the platform) will provide an infrastructure which makes developing gateways relatively easy. Further, as I stated in my previous post, I think it provides ColdFusion developers, gateway developers, and the ColdFusion community with a common interface and language for describing it. Now, as to your argument as a whole, I don't think it's a mistake to say you've spent a good deal of your time in this thread arguing that ColdFusion gateways offer very little. You've argued that very few applications built in ColdFusion will have a use for gateways because very few J2EE applications utilize JMS. Though I agree that a small percentage of applications will use them, I think most developers will use gateways in their applications at some point. By way of example, a relatively small percentage of my applications use COM interoperability, Web services, or even the cfdirectory tag. Nevertheless, I find those features indispensable. You've also stated that you don't believe the built in gateways will be enough: "What is the likelihood of the built-in gateways doing everything you need?" In my previous message, I stated that I think the gateways already announced sound like they'll suffice for most of what I've already dreamed up. I hope to be proven wrong because that means I will have found new uses for gateways. :) All in all, you've been arguing that you can already build gateway-like interfaces which invoke ColdFusion pages (ostensibly using Java or another lower level language to detect the event and invoke a ColdFusion page via HTTP?). For these reasons, you've implied (strongly) that gateways are a waste of Macromedia's resources. Do you still think I'm missing the context? -ben

>> CF-Admin... If I could get DSN-less connections with >> CFMX, I'd be all >> over it. > Umm, you can, with the service factory java objects... And use that for cfquery how? ... I know that I can connect to datasources without using a DSN by hacking the Java, and I know that I can create new DSN's on the fly using the serviceFactory -- neither of those are what I want. I want to be able to connect to a database on the fly to use <cfquery> against it without needing a dsn. Hell, the 2nd url in my sig is an article about accessing datasources through the serviceFactory. s. isaac dealey     954.927.5117 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.sys-con.com/story/?storyid=44477&DE=1 http://www.sys-con.com/story/?storyid=45569&DE=1 http://www.fusiontap.com

> And use that for cfquery how? ... I know that I can connect to Well, either write your own cf_query, or a cfquery object/UDF to behave like cfquery did back when CF support DSN-less nativly (4.5 ?)... all you are doing with hacking the java is what CF would have to do behind the scenes anyway. > 2nd url in my sig is an article about accessing datasources through I ignore urls in sigs, or ones longer than 4 lines. Yes, I know about mine - 'company policy' :-( -- Tom Chiverton Advanced ColdFusion Programmer Tel: +44(0)1749 834997 email: tom.chiverton@bluefinger.com BlueFinger Limited Underwood Business Park Wookey Hole Road, WELLS. BA5 1AF Tel: +44 (0)1749 834900 Fax: +44 (0)1749 834901 web: www.bluefinger.com Company Reg No: 4209395 Registered Office: 2 Temple Back East, Temple Quay, BRISTOL. BS1 6EG. *** This E-mail contains confidential information for the addressee only. If you are not the intended recipient, please notify us immediately. You should not use, disclose, distribute or copy this communication if received in error. No binding contract will result from this e-mail until such time as a written document is signed on behalf of the company. BlueFinger Limited cannot accept responsibility for the completeness or accuracy of this message as it has been transmitted over public networks.***

>> Like all things CF, it's more accessible to people who >> aren't Java experts. >> > Writing an event gateway requires knowledge of Java > therefore yours is not a valid argument. Excuse me? MM is providing a handful of pre-built gateways to begin with, much less having a consistent interface provided by MM which allows others who are Java knowledgeable to create, package and distribute additional gateways. At which point, yes, it is a very valid argument. The end result will be that developers who are not Java knowledgeable will be able to do things which would otherwise require extensive knowledge of Java. ----- Excess quoted text cut - see Original Post for more ----- <cfset mystruct.mykey = 0> I use the CF -- CF uses the Java object. This is not the same thing as me using the underlying Java object. ----- Excess quoted text cut - see Original Post for more ----- Probably. But very few (if any) are using their own application schemes instead of <cfapplication>. s. isaac dealey     954.927.5117 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.sys-con.com/story/?storyid=44477&DE=1 http://www.sys-con.com/story/?storyid=45569&DE=1 http://www.fusiontap.com

----- Excess quoted text cut - see Original Post for more ----- My response was in relation to writing an event gateway; not using an existing one. CF does not make it easier or harder to write an event gateway since you can only write an event gateway in CF. Further, writing an event gateway requires knowledge of Java. Thus, you argument is not valid. If you are going to argue against me then you have to stay in the context of the thread of positions don't make sense. > <cfset mystruct.mykey = 0> > > I use the CF -- CF uses the Java object. This is not the same thing as > me using the underlying Java object. > What about <cfset mystruct.put("foo", "bar")>? > Probably. But very few (if any) are using their own application > schemes instead of <cfapplication>. > What does that have to do with cflogin or frameworks? -Matt

At 01:35 PM 8/18/2004, you wrote: ----- Excess quoted text cut - see Original Post for more ----- It has to do with Mach-II blowing all other frameworks away. That is, except Java Server Faces and Struts. -- Alex

Hmm, that's an interesting point on flash generation... Did New Atlanta just get left behind big time in the compatability dept? Subj:  RE: BLACKSTONE: Software Development Times Article I don't know what to do with you Tony. You keep posting comments with no basis in facts that don't make much sense anyway. I'd really like to avoid addressing them or falling prey to my desire to respond negatively. Is that what you want? Is there some point to your comments? For the rest of you reading this, I have no financial interest in the success or failure of BlueDragon. Although, I would like to see them succeed. I don't know whether New Atlanta will implement the event gateway. I don't know whether they can. I certainly think they should implement it if for no other reason then to be compatible with ColdFusion. We all want that right? Personally, if I were to guess which functionality would be hard to implement in BlueDragon I wouldn't guess something like the event gateway. I would guess something that produces Flash on the fly. -Matt ----- Excess quoted text cut - see Original Post for more -----

Hmmm...the answer to that is unclear, and depends on your perspective and what features you need most. If you rely heavily on Flash integration, then my guess is the ColdFusion will always be a better choice than BlueDragon. On the other hand, if you're looking for ASP.NET integration (for example), then BlueDragon is the obvious (only) choice. As for "lagging big time in the compatibility dept", I'll only point out the Blackstone is finally delivering in 2005 features that were pioneered by BlueDragon and have been in use by our customers since 2002 (standard J2EE WAR/EAR deployment, precompiled CFML templates for source-less deployment, CFIMAGE tag, etc.). Other more recent features, such as CFC serialization, are supported by BlueDragon 6.1 now, but won't be in Blackstone until 2005. So, again, the question of who is leading and who is lagging isn't as clear-cut as you might think. The feature sets of ColdFusion and BlueDragon will never be exactly the same, so the choice will come down to: which features do you need the most? Repeat slowly: choice is good...choice is good...choice is good... Vince Bonfanti New Atlanta Communications, LLC http://www.newatlanta.com ________________________________   Sent: Wednesday, August 18, 2004 1:45 PM   To: CF-Talk   Subject: RE: BLACKSTONE: Software Development Times Article         Hmm, that's an interesting point on flash generation... Did New Atlanta just get left behind big time in the compatability dept?        Date:  8/18/04 8:59 am   To:  CF-Talk   Subj:  RE: BLACKSTONE: Software Development Times Article      I don't know what to do with you Tony. You keep posting comments with no   basis in facts that don't make much sense anyway. I'd really like to avoid   addressing them or falling prey to my desire to respond negatively. Is that   what you want? Is there some point to your comments?      For the rest of you reading this, I have no financial interest in the   success or failure of BlueDragon. Although, I would like to see them   succeed. I don't know whether New Atlanta will implement the event gateway.   I don't know whether they can. I certainly think they should implement it if   for no other reason then to be compatible with ColdFusion. We all want that   right?      Personally, if I were to guess which functionality would be hard to   implement in BlueDragon I wouldn't guess something like the event gateway. I   would guess something that produces Flash on the fly.      -Matt     

I think Vince is making some very good points here - remember that New Atlanta have always said that they are going after a slightly different audience to Macromedia and therefore the features they add for their customer base are likely to be slightly different to those added by Macromedia for their customer base. Tim (Buntel) has effectively said the same thing: Macromedia add what their customers ask for. If both sets of customers ask for the same thing, you can expect to see it implemented in both products - if they ask for different things then you will naturally get some level of incompatibility. ----- Excess quoted text cut - see Original Post for more -----

> It has to do with Mach-II blowing all other frameworks away. That is, > except Java Server Faces and Struts. > Glad you cleared that up. ;) -Matt

At 01:46 PM 8/18/2004, you wrote: >> It has to do with Mach-II blowing all other frameworks away. That is, >> except Java Server Faces and Struts. >> >Glad you cleared that up. ;) I'm sorry...I just can't help myself. As I was typing the above response, I could see a red-faced "FuseBoxer" knee-deep in a "nested circuit" just blowing a gasket at the insinuation that Struts or JSF could be mentioned in the same breath as FuseBox. I can't begin to imagine what the OnTap, CF/MVC and Tapestry camps are thinking. Cheers!  :-) -- Alex ----- Excess quoted text cut - see Original Post for more -----

Why? They're all fine frameworks. No gasket-blowing in sight (unless one considers your random irrational generalizations as blowing a gasket). I'm sorry...I just can't help myself. As I was typing the above response, I could see a red-faced "FuseBoxer" knee-deep in a "nested circuit" just blowing a gasket at the insinuation that Struts or JSF could be mentioned in the same breath as FuseBox. I can't begin to imagine what the OnTap, CF/MVC and Tapestry camps are thinking. Cheers!  :-) -- Alex

----- Excess quoted text cut - see Original Post for more ----- Didn't realize it was in that context... but okay -- since I read the other one where you quoted the context you were speaking within specifically -- the _minor_ revision then is -- "if you don't like the way the pre-built gateways work, buy or use one someone else has built", which is still a lot easier than building one yourself if you don't have lots of Java expertise. The fact that CF provides a consistent framework for that means that it will be easier for people who have Java expertise to provide them to people who don't. Even if it's only a linguistic thing, the fact that people are talking about the CF native feature will mean they will be more accessible in all likelyhood - there will be more information about them, etc and likely more people will be looking for them (and on the other side of the supply-demand system building) once it's a part of the common language of native CF features. ----- Excess quoted text cut - see Original Post for more ----- I could, but I don't. So... that doesn't change my statement any. ----- Excess quoted text cut - see Original Post for more ----- You'd made the comment that MM is historically not good at creating frameworks for people to use in comparison to the CF community. I was just pointing out a notable exception. context, context. :) s. isaac dealey     954.927.5117 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.sys-con.com/story/?storyid=44477&DE=1 http://www.sys-con.com/story/?storyid=45569&DE=1 http://www.fusiontap.com

Nothing wrong with Fusebox. Nothing wrong with any framework or methodology... Whatever works for ya. Michael T. Tangorre   ----- Excess quoted text cut - see Original Post for more -----

----- Excess quoted text cut - see Original Post for more ----- That is a fair argument, but I think it is too early to tell whether the event gateway will provide this consistency. Again, the framework it provides could be great, but it could also suck. That is the great thing about community frameworks; if they suck you can avoid them and use something that doesn't. If the framework is built-in then you have little choice to use something else. > I could, but I don't. So... that doesn't change my statement any. > My point is that the following are all the same: <cfset mystruct.foo = "bar"> <cfset mystruct["foo"] = "bar"> <cfset mystruct.put("foo", "bar")> The first two lines are CFML syntax, while the last line is Java syntax. They all work because a struct is in fact a Java object. Therefore, any of those lines above are uses of a Java object. > You'd made the comment that MM is historically not good at creating > frameworks for people to use in comparison to the CF community. I was > just pointing out a notable exception. > I don't consider <cfapplication> to be a framework. -Matt

> That is a fair argument, but I think it is too early to tell whether > the event gateway will provide this consistency. In that case, isn't it too early to be having this discussion? Or at least, to expect it to be a meaningful discussion? > Again, the framework it provides could be great, but it could also > suck. That is the great thing about community frameworks; if they suck > you can avoid them and use something that doesn't. If the framework is > built-in then you have little choice to use something else. Just because something is built-in doesn't mean you have to use it. There are plenty of CFMX applications using something other than CFLOGIN and IsUserInRole for authentication and authorization, just as there were plenty of CF 5 applications that didn't use CFAUTHENTICATE, etc. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444

> In that case, isn't it too early to be having this discussion? Or at > least, > to expect it to be a meaningful discussion? > Not at all! This is the perfect time to air concerns regarding Blackstone as it allows Macromedia time to address them before the product ships if they choose to. They may have already addressed the issue or they may not have thought of it. Better to be safe and discuss it now. > Just because something is built-in doesn't mean you have to use it. There > are plenty of CFMX applications using something other than CFLOGIN and > IsUserInRole for authentication and authorization, just as there were > plenty > of CF 5 applications that didn't use CFAUTHENTICATE, etc. > Maybe, but it also might not be possible to invoke CFC's from alternate protocols without using the event gateway thus requiring you to use it. -Matt

NDA reminder here for anyone under NDA. Thanks >> In that case, isn't it too early to be having this discussion? Or at >Not at all! This is the perfect time to air concerns regarding Blackstone as

> Not at all! This is the perfect time to air concerns regarding > Blackstone as it allows Macromedia time to address them before the > product ships if they choose to. They may have already addressed the > issue or they may not have thought of it. Better to be safe and discuss > it now. I don't see how they can be expected to respond to this. MM has said there will be an event gateway. You're saying it might have been a waste of their time. Do you expect them to remove the feature if enough people say it's not worth the time? In any event, it's hard to predict what will be popular or useful beforehand. I can't count the number of times I've thought something would be a really neat feature, but it turned out to be less useful than I expected. The converse is also true. > Maybe, but it also might not be possible to invoke CFC's from alternate > protocols without using the event gateway thus requiring you to use it. I don't see how that would be possible, given that you said it should be possible to do this today using non-MM code. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444

LOL tony u can speak 4 me anytime, gives me more time to go fishin! <cfset goodFlyFishingDay = weather EQ rain AND clouds EQ overcast AND season NEQ winter> Reply-To: cf-talk@houseoffusion.com Date:  Wed, 18 Aug 2004 09:38:08 -0400 ----- Excess quoted text cut - see Original Post for more -----

> LOL > tony u can speak 4 me anytime, gives me more time to go > fishin! > <cfset goodFlyFishingDay = weather EQ rain AND clouds EQ > overcast AND season NEQ winter> Syntax is a bit odd... not sure it will work that way, try this: <cfset overcast = ran & clouds> <cfif weather eq overcast and season neq winter>   <cfset goodFlyFishingDay = true> <cfelse>   <cfset goodFlyFishingDay = false> </cfif> :) s. isaac dealey     954.927.5117 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.sys-con.com/story/?storyid=44477&DE=1 http://www.sys-con.com/story/?storyid=45569&DE=1 http://www.fusiontap.com

Competition is good..... competition is good..... ;) Micha Schopman Software Engineer Modern Media, Databankweg 12 M, 3821 AL  Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380