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 ----------------------------------------

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:

> 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:

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

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!  

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:

> 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

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?

Matt Liotta wrote: 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

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... %^)> 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:

At 11:46 AM 8/17/2004, you wrote: LMAO! TTFN, Alex

Matt Liotta wrote: 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   _____   From: Matt Liotta [mailto:mliotta@r337.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