Re: A suggestion for FuseBox viability. . .

[Nate Nielsen]

Well, to be fair, the first paragraph of the website is . . .   "Fusebox is a FREE web application standard in use by 7521 people from around the world. Fusebox is attempting to reduce the 70% software failure rate by creating a standard methodology for writing web applications. This development methodology works with ANY web application small and large. Join us and have your ideas be heard by thousands of professionals around the world." Perhaps the confusion comes from the fact that in just this one paragraph, 2 of the 4 sentances directly state FuseBox as a methodology. Macromedia's description next to Hal Helms pic is . . .   "Hal Helms teaches, writes, speaks, and consults on Web development using the Fusebox methodology." And I remember reading an article by Hal about different common methodologies, such as the "No Methodology Methodology", "Proprietary Methodology", etc.  This article was evangalizing the use of the "FuseBox Methodology"   - My point being, is that FuseBox IS billed out as a methodology, by its highest members and even the primary website.   My simple request is that :  (A) Abandon the thought of FuseBox as a methodology.  Especially with FB3 - We could possibly stretch the meaning of "methodology" a bit for previous versions, but FB3 is far from a methodology, we all know and understand this.  (B)  Clearly define FuseBox as a framework, and post it as such.   My personal feeling is that the term "methodology" states a form of developing against a set of standards and best practices.  The existing "methodology" concept for the product creates a better stance for exposure and acceptance for it's inherent meaning to the over-lords that manage development groups - however it is mis-leading.   I still truly think if you define FB as a framework, and release a second product as a straight methodology - and refrain from making direct references to each other in both.  These two as separate entities should be able to exist without one another - as they address different needs.    -Lets face it, there is a clear and strict distinction in the development community over FB, you love it or hate it - normally there not being a third choice.  I think by taking a few simple steps to clear up the confusion, FB would much more popular, and bring the FB Haters Club and FB Lovers Club  together.     Nate Nielsen [EMAIL PROTECTED] [EMAIL PROTECTED]   ----- Original Message ----- From: Lee Borkman To: [EMAIL PROTECTED] Sent: Friday, May 10, 2002 5:14 PM Subject: Re: A suggestion for FuseBox viability. . . Hi Nate, Fusebox was never a methodology.  An architecture or possibly even a framework these days, but not a methodology.  For some historical reasons that I do not claim to understand, Fusebox has often been referred to as "The Fusebox Methodology", but that was and is a simple misnomer. IMHO. ;-)   Of course, along the way, many FB users have adopted methodologies that work well with the FB architecture, and much of this useful practice is now being crystalised into what is called "FLiP", the Fusebox Lifecycle Process.  You can choose FB architecture.  You can choose FLiP methodology.  You can choose both, or one, or neither.  The architecture is portable, and has been ported to several different languages/platforms.  The soon-to-be-convened Standards Committee wil no doubt be documenting in language-independent terms exactly what is and what is not FB3, so that it can be implemented for many more languages.  Even the FLiP methodology is portable, in that you can use it for doing things other than developing web applications.   In the very near future, you can expect at least one book to be published about the FB3 framework.  It has nothing to say about methodology.  No doubt there will be other books to follow that document the FLiP methodology, and that will say nothing about FB3.  And yes, there is another book about to pop up that talks about both.   In short, I hope and believe that your concerns are already being addressed.  Watch this space.   See ya, Lee Borkman The Fusebox Steering Committee ----- Original Message ----- From: Nate Nielsen   A suggestion for FuseBox.  Seperate it -   Official FuseBox Methodology  -  Methodologies can be contained in a document and require no files.  They explore best practices for approaching common development tasks.   Official FuseBox Framework - This is basically what FB3 is.  It can require files, and take care of issues on a coding level.  You can add the handling of errors and exceptions and other widgets.  Most importantly, it can cater to specific languages.   I think many people are turned off by the fact that the FuseBox methodology is now a framework.  This also makes it impossible to actually port FB as a methodology over to other languages like ASP and JSP.   I think if the "FB Steer" folks got back to the basics of developing FuseBox as a methodology, and framework for those interested in it, -seperately- you would see many doors open to expanding FB concept on a much larger scale.   And no, I don't think this post belongs in community, and therefore - I will not take it there.   =)   Everyone's thoughts on this? ==^================================================================ This email was sent to: archive@jab.org EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================