Larry,
Don't know that I have "answers" to the points you raise, but at least some
thoughts on them. :-)
Although Java was always part of the roadmap, until now the form that might
take wasn't clear. Obviously, there are a lot of open questions still -- and
MM will need to provide additional data as we move forward -- but we now
have a direction with lots of "pluses." MM has also been very receptive to
the idea of involving Spectra developers early and frequently in the
development of the next phase of the COAPI. I think the prospects of that
are quite exciting.
I'm guessing that this was a tough decision, but I'm also guessing that it
was both a business and technical decision. As much as I like Spectra, I'm
not sure I'd want the next version of the COAPI to have to be tied to being
100% backward compatible. There are enough things that we'd like to see
tweaked and improved about it and I�d prefer to have the �break� now rather
than in a couple of years. (I�ve also heard, although it is unconfirmed,
that Spectra may run on Neo. If that�s the case, it provides a way to run
Spectra in the Java world without changing the code.)
For example, I thought searching into objects through the Properties table
was a clever way of representing an object-based paradigm into a relational
database, but there may be better, more scalable ways to handle this. In
particular, I'd like to avoid the sometimes complex multiple joins to the
Properties table to find objects.
With regards to the personalization you mention, I agree that people are
going to want to have advanced personalization. (Although current clients
often mention personalization no one seems to be buying solutions
specifically for personalization yet -- perhaps in another 6 to 12 months
there'll be enough education in the marketplace (and on my part!) to really
understand what it is all about.)
I'm not sure the new direction precludes advanced personalization. I haven't
heard anything specifically about it, but as we're moving onto the J2EE
platform and Open Sesame is Java-based, it may make the integration easier
or faster.
In connection with this, I'd personally like to see a re-examination of the
way object metadata was stored and managed. Using Verity for that caused
some peculiarities as did storing metadata strings into each object. I
understand that putting the actual strings into the objects was a way to
make the data available very quickly when dealing with individual objects,
but at the same time, I found it to be a pain to have hardcoded strings
scattered throughout the CODB. Perhaps now we have the opportunity to
re-examine that approach.
There are probably other pet-peeves that people have about Spectra
implementation details. While the new version is obviously not going to be a
panacea, I think it gives us as a community the opportunity to re-examine
those issues and come up with improved solutions. As long as the underlying
vision of the COAPI remains, I think we're on solid ground.
In terms of the additional services that Spectra provided that are not going
to be moving forward, I may be in a bit of a unique position -- most of our
applications concentrated on the COAPI because we felt it was the strongest
part of Spectra.
That may not be the case for other developers who relied more heavily on the
other services. While there may be no easy answer that covers all
situations, I do think that:
1) The community source project will help address those issues, headed by
someone everyone in the Spectra community knows and respects. The
possibility was raised in the last day as to whether new functionality might
be added to Spectra or if we are only talking about bug fixes. At the risk
of being shot down by Ray, I'd like to think that the community source model
provides the opportunity to add or evolve functionality.
2) Those Spectra services that have proven themselves to be of value to
people will likely be moved into the new paradigm. Whether MM supplies the
code or it is done by an individual developer, we've moving into a world
that allows for much greater customization. If the underlying architecture
is honed and performance improved, everything built on that architecture
will benefit.
Perhaps this is a bit unfair, but as an extreme example, would I prefer that
MM invest its R&D dollars into developing the COAPI or into the Webtop?
Well, the webtop was a pretty cool Spectra app, but we couldn't use it as
the admin interface for our clients. That is not a criticism of the Webtop
designers or team -- all of us are dealing in high end web sites that take
lots of custom programming. It's unlikely that one solution is going to be
built that pleases everyone. I rather have affordable, solid,
high-performance tools and re-usable code that lets me do my job of building
web sites. I'd prefer they redirect the development talent invested in the
Webtop and spend it in more fundamental areas, namely the COAPI.
I guess I see the new direction as an evolution rather than an abandonment.
The Spectra brand is going to continue. Its code base will move forward. And
its fundamental concept is going to evolve into a stronger, more scalable
form.
I guess I do find that exciting!
David
-----Original Message-----
From: Lanny R. Udey [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 24, 2001 9:51 AM
To: Spectra-Talk
Subject: RE: The Future of Spectra
David,
>>> [EMAIL PROTECTED] Tuesday, April 24, 2001 >>>
>...I've had to stifle my excitement for the
>last week and a half since we first learned about the new initiative and
>direction ..
I fail to see where the excitement comes from. Building the COAPI as Java
was always part of the roadmap for Spectra. Now we get the Java COAPI but no
Spectra update to make this transparent. Remember we paid real $$$ for this.
>I think Spectra has been (and will continue to be) a good implementation of
>the COAPI. But I also think it can evolve.
We get the privilege of contributing to an open community source...I could
have done this with PHP or Perl at no charge.
>The prospect of working with a COAPI that is tightly integrated with the CF
>Server, runs with the performance of Java and opens the door to the entire
>world of J2EE is very appealing. I just wish it was here NOW! :-)
I will buy this one but this was planned anyway.
>1) None of our projects were waiting for additional functionality that we
>hoped might get included in a future version of Spectra. With 1.5, pretty
>much all the key features we wanted were included (notably versioning).
Wait till they want personalization vis-a-vis Open Sesame or other new
products that might have found there way into Spectra and then they find out
that they now have to purchase this separately instead of getting them under
maintenance.
>In connection with this we realized that our current (and upcoming)
>customers are not going to HAVE to move to the new code if they don't want
>to -- they will be able to stay with Spectra for the expected life of their
>apps if they choose. Or they can move if they want to or if they see
>advantages to it for their particular app.
This begs the question - people buy into this kind of technology to be
guaranteed a smooth migration to future technology - that's why we are
willing to spend more money up-front and on maintenance. I am sure it is a
boon for developers who will now get to retrofit the existing applications.
>4) It appears that many of the Macromedia people we've worked with as
>Spectra developers are going to continue to be involved in the forward
>motion of both Spectra and its new incarnation (Charles, Libby and Ray in
>particular come to mind). I think this bodes well for the future.
Despite Charles sanguine message, I can't help but believe that this
decision hurt. I met with them a couple of months ago and at that time they
had great plans for the Dharma release of Spectra.
>David Aden
>Webworld Studios
Lanny Udey
Associate Dean
Learning and Information Technology
Hofstra University
[EMAIL PROTECTED]
-----Original Message-----
From: Charles Teague [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 5:20 PM
To: Spectra-Talk
Subject: The Future of Spectra
Hi everyone. We really appreciate everyone's patience over the last few
weeks. There has been a lot of discussion and concern over the future of
Spectra, and I think that the time is right to shed some light on what we
are thinking.
As you know, Spectra provides developers with a broad set of functionality
and technology. Enough so, sometimes its breadth proves daunting.
Fundamental to the entire product, however, is its foundation - the content
object API. In 1996, when I first started working on Allaire's website, the
foundational change that I went through was around thinking about the site
as composed of 'content objects.' Over the last 5 years, this core concept
has been revised, revolutionized, improved, and expanded. Spectra has been
the product that carried this concept forward. This concept, and the content
object API, have been the most compelling pieces of Spectra since its
inception.
Macromedia's goal is to make dynamic content technology like the content
object API pervasive, approachable, and cost effective for our developers.
To help us better achieve this, we plan to incorporate key components of
Spectra technology - a Java-based version of the COAPI architecture and
other services directly related to dynamic content - into the application
server, as well as delivering next generation dynamic content technologies
such as end-user content contribution and team production through a series
of new product initiatives. This means that version 1.5 will be Spectra's
last feature additive release - we'll invest our resources in making the
core technology that we move into our application server and visual tools
faster, easier, and better.
Macromedia will continue to support Spectra via a community source model,
on-going technical support, training, and consulting, as well as having a
team of engineers working on bug fixes and quality assurance for community
source submissions. Spectra will continue to be offered for sale, using our
partners as the primary sales channel. We also will do our best to give you
early access to technology previews, alphas, and betas of the new
technologies already under development.
In the world we live and work in, technology changes constantly, we've all
thrived because of our ability to adapt to change. This is no different - a
change for the Spectra Product Group, and for every developer, customer and
partner out there who has invested their valuable time and mind share into
Spectra. While I understand the challenge that a change like this can pose,
I am extremely optimistic. The core vision of the Spectra technology is
compelling - the opportunity to make this technology available to more
developers, cheaper, and better, is a chance that I relish. I hope you
share my optimism through this time of change.
You can direct questions and comments to a couple of places:
1) Via Phone at:
866-236-1146 (North America Toll Free)
800-25524731, (International Toll Free)
617-219-3010 (Direct Dial Long Distance)
2) Via Email:
[EMAIL PROTECTED]
I can speak for the Spectra Product Group and Macromedia when I say how much
we value the community of developers that use our products. Spectra is no
exception. We have an incredible community, and one that we want to
continue.
-c
-------------------------------------------
Charles Teague
Director, Engineering
[EMAIL PROTECTED]
-------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
