Macromedia Flash opened up!!
p.m
Hi!
Head on over to macromedia's site (http://www.macromedia.com).
3 announcements: Flash 3, Flash generator, and the Flash File Format
opened up!
http://www.macromedia.com/software/flash/open/whitepaper/
Macromedia announced it will submit the .swf file format to the internet
standards body group. Flash may well be come *the* vector graphics
standard for the web.
Id be interested to hear from folks who would be intrested in making
flash a naitive file format for mozilla. Any takers?!
paul mend.
pa...@flasher.net
James M. Cape
Sounds good to me... :-)
Jim Cape
Graphic Designer
http://www.jcinteractive.com
Netscape DevEdge Champion, Client-Tech Newsgroup
snews://secnews.netscape.com/netscape.devs-client-technical
"Television — a medium. So called because it is neither
rare nor well-done."
— Ernie Kovacs
Bryce Harrington
On Tue, 14 Apr 1998, Glynn Clements wrote:
> This begs the question of whether Mozilla *needs* a `native' vector
> graphics format. Or for that matter whether it needs *any* native file
> formats.
> However, I can't see any reason why bitmapped graphics formats can't
> be handled by plug-ins, and the same applies to vector graphics
> formats.
Perhaps so, but having a built-in, dependable vector graphics format
opens up possibilities -- for example, it makes moving the GUI elements
from the chrome to the view much more reasonable.
Bryce Harrington
bryce @ alumni.caltech.edu
Gregory R. Block
> This begs the question of whether Mozilla *needs* a `native' vector
> graphics format. Or for that matter whether it needs *any* native file
> formats.
Good question. Considering that most of the core functionality will exist as
modules *anyways*, on the other hand, probably means that it's a question that
really doesn't matter. The issue of whether a 'native' vector module ships
with the mozilla build or not is a build compilation issue, not necessarily an
integration issue.
OTOH, I think that it could bring a lot of really nice functionality to
layout: Imagine if you could define a layer's shape, for example, using such
a format.
> However, I can't see any reason why bitmapped graphics formats can't
> be handled by plug-ins, and the same applies to vector graphics
> formats.
Good reasons for integrating vector format handling into the core Mozilla
distribution (aside from modularity - of course, it should be a module):
* Support broad use of vector graphics and a migration from bitmap graphics
where such support could/would be more effective.
* Integration of the vector graphics system into the DOM
* Possible use of the vector graphics engine in style sheets
* Integration of the vector graphics system into Mozilla-JS
OTOH, I don't think Macromedia's Flash is the right answer. PGML is cool
because...
* PGML is based on XML
* PGML will be easy to output from js document.write() commands
* PGML can be sent inline in a document as well as externally from a file
* PGML has a clear way of integrating into the DOM
* PGML supports scriptability for content integration and behavior modelling
* PGML is easily generated, which means that dynamically generated PGML based
on information in databases is a walk in the park.
* PGML has a guy from Netscape in the list of contributors, which makes it
innately cooler than Flash. :)
OTOH, Macromedia's has quite a few cool bits.
* Flash can be streamed easily.
* Flash defines lots of compression formats.
* Flash has cool tools for building the files already available.
* Flash already has broad acceptance as a 2D vector format.
* Flash supports timelines for animation
* Flash supports morphing of 2D objects
* Flash supports packaged 2D vector, bitmap, and audio components
OTOH, Macromedia's licensing leaves something to be desired for the Mozilla
community.
* Source code will be available to partners through licensing (and is
therefore not open-source)
p.m
Gregory,
Macromedia Flash many advantages over PGML.
1. Flash is real, PGML is a concept on paper
2. Flash has a huge install base.
3. Flash has a legion of designers already familiar with the technology.
There are also various websites that provide documentation and support
(mine included)
4. Flash supports many platforms (68k mac, powerpc, win 3.1, win 95/NT,
java). PGML support will be based on the browser support
5. The Flash Generator allows for dynamic data driven animations. This
product is hot! It allows for variable content in both animation clips
and text strings. It will also export content in gif/jpeg format.
6. Flash is already scriptable via liveconnect / activex. Tighter
integration with mozilla would be beneficial.
7. Flash allows for sophisticated animations in a way that PGML could
never allow. (A text descriptoin of an animation, especially in the
postscript like manner that PGML describes itself, would require an
enormous amount of complex information. Well beyond a coder's abilities.
Well beyond a well scripted cgi app. Within the means of an authoring
environment...but then again PGML doesnt have an authoring environment)
8. Flash allows for other flash movies (externally located) to be
incorporated in a single file stream. This allows for a multitude of
source files.
If you had too choose between an existing, proven format and a proposed
one, you would have an easier time looking at the existing one, since it
exists. You would have to then evaluate if the proposed one is even
worth developing. Does it offer features that the exisitng one doesnt?
Just some thoughts to consider.
regards
paul
pa...@flasher.net
Gregory R. Block wrote:
> OTOH, I don't think Macromedia's Flash is the right answer. PGML is cool
> because...
>
> * PGML is based on XML
> * PGML will be easy to output from js document.write() commands
> * PGML can be sent inline in a document as well as externally from a file
> * PGML has a clear way of integrating into the DOM
> * PGML supports scriptability for content integration and behavior modelling
> * PGML is easily generated, which means that dynamically generated PGML based
> on information in databases is a walk in the park.
> * PGML has a guy from Netscape in the list of contributors, which makes it
> innately cooler than Flash. :)
>
> OTOH, Macromedia's has quite a few cool bits.
>
> * Flash can be streamed easily.
> * Flash defines lots of compression formats.
> * Flash has cool tools for building the files already available.
> * Flash already has broad acceptance as a 2D vector format.
> * Flash supports timelines for animation
> * Flash supports morphing of 2D objects
> * Flash supports packaged 2D vector, bitmap, and audio components
>
> OTOH, Macromedia's licensing leaves something to be desired for the Mozilla
> community.
>
> * Source code will be available to partners through licensing (and is
> therefore not open-source)
>
> ------------------------------------------------------------------------
>
> Gregory Block <gbl...@netscape.com>
> Senior Security Consultant
> Netscape Communications GmbH
>
> Gregory Block
> Senior Security Consultant <gbl...@netscape.com>
> Netscape Communications GmbH HTML Mail
> Netscape Communications GmbH Netscape Conference Address
> Airport Office Park, Am Soldnermoos 6 Netscape Conference DLS Server
> Hallbergmoos
> Munchen
> D-85399
> Germany
> Homepage: http://people.netscape.com/gblock/ Personal address: gbl...@lemon.net Personal website:
http://www.lemon.net/~gblock/
> Additional Information:
> Last Name Block
> First Name Gregory
> Version 2.1
Gregory R. Block
> Macromedia Flash many advantages over PGML.
Yes and no. :)
> 1. Flash is real, PGML is a concept on paper
Flash is a real, commercial product. Flash source is available under specific licensing terms which are not
free source terms. Which means that, for all intents and purposes, Flash and PGML have the same level of
support within the free software community, i.e., none. :)
> 2. Flash has a huge install base.
Which I noted. I'm one of them, I think it's the bollocks. :)
> 3. Flash has a legion of designers already familiar with the technology.
> There are also various websites that provide documentation and support
> (mine included)
Again, understood. OTOH, Macromedia is good at building tools for anyone's technology; look at Dreamweaver,
for example. So while *current* tools availability is a bonus for Flash, *future* tools availability will be
available for either.
> 4. Flash supports many platforms (68k mac, powerpc, win 3.1, win 95/NT,
> java). PGML support will be based on the browser support
PGML is possible as a plugin, just as flash is; PGML inline support may require browser customisations.
Flash's support for many platforms doesn't matter because the SDK isn't free. So the free software community
must start from scratch *regardless*.
If we're not talking about creating free source for Flash, then the opening of the format means absolutely
nothing. Since we are, it means Flash is on equal footing with PGML in the engine and portability department
- because neither actually exist in the free source world.
> 5. The Flash Generator allows for dynamic data driven animations. This
> product is hot! It allows for variable content in both animation clips
> and text strings. It will also export content in gif/jpeg format.
Flash Generator wouldn't be necessary if Flash's file format was based on XML. If I can write client-side
JavaScript to output PGML graphics on the fly, and I can write server-side applications which write out PGML
graphics, then I can essentially do what Flash Generator can do *and more*, because now I can do things in
the client to animate the graphics as well as embedding that information into the PGML for self-enclosed
animations.
More importantly, because PGML integrates into the DOM, it's accessible from scripting languages and style
sheets.
> 6. Flash is already scriptable via liveconnect / activex. Tighter
> integration with mozilla would be beneficial.
Flash doesn't define a DOM integration currently.
> 7. Flash allows for sophisticated animations in a way that PGML could
> never allow. (A text descriptoin of an animation, especially in the
> postscript like manner that PGML describes itself, would require an
> enormous amount of complex information. Well beyond a coder's abilities.
People said that about Dynamic HTML, as well. Macromedia Dreamweaver and NetObjects Fusion 3 happily prove
that tools can do wonderful things when given a powerful enough description language.
And JavaScript isn't well beyond a coder's abilities any more than Visual Basic is. (I'll bet the Lords of
JavaScript just turned in their sleep. :)
> Well beyond a well scripted cgi app.
PGML supports scripts embedded in the PGML, and displays PGML components to the document object model, making
every graphical component accessible from browser scripting language and allowing for on-the-fly creation and
modificatio of graphics in PGML format.
Flash doesn't support the option of being embedded into a document, and is based on a plugin model that will
not allow page-level integration.
> Within the means of an authoring
> environment...but then again PGML doesnt have an authoring environment)
Valid assessment.
> If you had too choose between an existing, proven format and a proposed
> one, you would have an easier time looking at the existing one, since it
> exists. You would have to then evaluate if the proposed one is even
> worth developing. Does it offer features that the exisitng one doesnt?
In this case, the existing, proven format doesn't support the DOM, doesn't allow for easy on-the-fly
generation, doesn't provide for enough scriptability,
And if you think JavaScript DHTML is too difficult, watch my homepage. Next week, the BollocksFinder goes
online, complete with drop-down menus, scrollable text areas, status notification, and whizzy graphics.
There might even be some interesting content to read, if I'm lucky.
It's not rocket science. As the Liberators might say, "DHTML ain't from Detroit, ain't intelligent, but it's
f*ckin 'avin it". (London Acid City fans unite)
On the other hand, Flash does what it claims to, it works, and it's got a lot of support in the industry. It
has working tools. It has server components. It has streaming support. It has easily definable behavior by
looking at current implementations. It allows for tagged extensibility of the format. It's attractive for
those reasons.
But it addresses a very different type of market than PGML.
:plur,
Greg
p.m
Gregory R. Block wrote:
[snip]
>
> Again, understood. OTOH, Macromedia is good at building tools for anyone's technology; look at Dreamweaver,
> for example. So while *current* tools availability is a bonus for Flash, *future* tools availability will be
> available for either.
True, and my guess would be other will try to hobble PGML to do what
Flash does now. Why not take Flash further in the tools available
(adding macro and plugin support for example)? Evolve the tools, not
reinvent the format.
[snip]
> Flash's support for many platforms doesn't matter because the SDK isn't free. So the free software community
> must start from scratch *regardless*.
I dont understand this comment. Because Flash's source is not available
for free, then it doesnt matter? Rather, as you state, it doesnt matter
to the free software community. However, its very much in the intrest of
the free software community to merge mozilla with the appropriate API's
to handle something like flash as a native file format. Because that
kind of support of a market standard *is* important for a free software
project. (just like linux's support for windows apps is VERY important
for its acceptance).
>
> If we're not talking about creating free source for Flash, then the opening of the format means absolutely
> nothing. Since we are, it means Flash is on equal footing with PGML in the engine and portability department
> - because neither actually exist in the free source world.
>
> > 5. The Flash Generator allows for dynamic data driven animations. This
> > product is hot! It allows for variable content in both animation clips
> > and text strings. It will also export content in gif/jpeg format.
>
> Flash Generator wouldn't be necessary if Flash's file format was based on XML. If I can write client-side
> JavaScript to output PGML graphics on the fly, and I can write server-side applications which write out PGML
> graphics, then I can essentially do what Flash Generator can do *and more*, because now I can do things in
> the client to animate the graphics as well as embedding that information into the PGML for self-enclosed
> animations.
In concept what you are saying sound great, but the reality is quite
different. PGML defines very basic shapes..post script like commands.
The fact of the matter is, complex animations are not made out of simple
shapes. Its not the javascript 1.2 model of moving layers from point 1
to point 2. Id like to see PGML description of something like what
spumco does or gabocorp. The file would be huge! It wouldn't be
practical to put it inside of a client side document.write.
And thats the point here. PGML cant do Flash *easily* as you claim. It
is at such a lower level of description. It can't claim to do anything
but simple animations (like moving circles, or boxes, or plotting
boxes).
So in theory PGML sounds great. Since its all text its easy to generate,
integrate with a scripting language, and integrate with DOM. But PGML
simply can't scale to the complexities required in even the most simple
animations (say a stick figure walking).
> More importantly, because PGML integrates into the DOM, it's accessible from scripting languages and style
> sheets.
[snip]
> > 7. Flash allows for sophisticated animations in a way that PGML could
> > never allow. (A text descriptoin of an animation, especially in the
> > postscript like manner that PGML describes itself, would require an
> > enormous amount of complex information. Well beyond a coder's abilities.
>
> People said that about Dynamic HTML, as well. Macromedia Dreamweaver and NetObjects Fusion 3 happily prove
> that tools can do wonderful things when given a powerful enough description language.
>
> And JavaScript isn't well beyond a coder's abilities any more than Visual Basic is. (I'll bet the Lords of
> JavaScript just turned in their sleep. :)
So why hasnt' DHTML take off? If creating thousand of lines of code in
javascript just to get something to act like a cdrom experience is so
easy, then why dont we see these kind of complex 'director' like
experiences created in DHTML?
Anyhow, why should anyone have to do that if an easier, friendlier tool
will create the same thing and better (add sound support, stream, etc).
> PGML supports scripts embedded in the PGML, and displays PGML components to the document object model, making
> every graphical component accessible from browser scripting language and allowing for on-the-fly creation and
> modificatio of graphics in PGML format.
This is back to the tools arguement. You need a great tool to see this
reality.
i remember a quote from one of the head people of the Dreamweaver team.
They basically said something like ' well we created dreamweaver because
we knew there was no possible way to create a GUI tool for every
possible DHTML type effect...since DHTML is essentially a programming
language its hard to abstract something so variable'
Terrible rephrasing (then again im so bloody tired right now) but the
point is no tool will ever sophiciatly abstract a programming language
such as javascript.
[snip]
> But it addresses a very different type of market than PGML.
And THAT my friend, is where we agree ;]
paul
pa...@flasher.net
> Greg
Ben Pennington
I believe that Macromedia will make a submission to
the W3C, at which point a spec will be drafted that
combines the best of both of them. This spec will be
what needs to be supported by mozilla. I've created
a website at www.lizardfx.org dedicated to putting
that module together.
Marc Byrd
Glynn,
I wholeheartedly agree, and this is the essence of a component strategy - to
make functionality that is well suited use the component api instead of
cutting and pasting similar layout code (like image->plugin->applet).
I agree with your position that even HTML be handled by a plugin. It needn't
be the case that the html component be ONLY a plugin, and it needn't be the
case that all of the advanced or generalized layout functionality live in the
html plugin, but yes, it should be in a plugin.
Along those lines, one of the directions I would like to see is the ability to
override all internal mimetype handlers (like IMAGE/JPEG , TEXT/HTML, etc.).
This would allow component development to start, with all of the associated
benefits (don't have to build the whole mozilla, independent schedules, mix
and match, consumer choice, etc.). I always joke that it shouldn't take a
physics geek like me to extoll the benefits of component technology to a bunch
of c.s. majors ;^).
Clearly, we also need to pay attention to SmartUpdate, so the sleds are
greased for users to get these new components. We also need to make it easier
to build and maintain plugins, along the lines of the build and revision
control facilities that support the mozilla codebase, and with an initiative
I'm presenting on a Plugin Builder Website - a web-based application that
assists the developer in building a skeleton of code, in the proper XP
(cross-platform) format, with the appropriate makefiles and configs, all ready
to go. I'll be posting a paper on this soon, calling for comments.
We also need to make plugins "first class" from the feature and support point
of view. Developers have to be confident that the plugin solution is every
bit as robust, performant, and feature-capable as would be glomming the
feature onto the monolith.
Finally, one more barrier originally concerned me, but now I think it's a
boon: One thing plugins can't guarantee is the shipment of the component to
every single desktop on the planet that uses the product the way an internal
solution can. One can't today seperate the internal GIF handler, so that code
is guaranteed to land, regardless of it's quality and features compared to
other GIF viewing implementations. This is a free market or consumerism issue
- users (and end-product packagers who serve those markets) shouldn't be bound
in that way to a certain solution. Make all of these things independent
components, and let the market decide.
marcb
aka by...@netscape.com
plugins module owner
Glynn Clements wrote:
> p.m wrote:
>
> > Macromedia announced it will submit the .swf file format to the internet
> > standards body group. Flash may well be come *the* vector graphics
> > standard for the web.
> >
> > Id be interested to hear from folks who would be intrested in making
> > flash a naitive file format for mozilla. Any takers?!
>
> This begs the question of whether Mozilla *needs* a `native' vector
> graphics format. Or for that matter whether it needs *any* native file
> formats.
>
> IMHO, this sort of thing should be delegated to a plug-in. Ideally it
> should even be possible to delegate HTML et al to plug-ins.
>
> HTML may be harder, as you would need to be able to have access to all
> of the browser's features, e.g. invoking other plug-ins.
>
> However, I can't see any reason why bitmapped graphics formats can't
> be handled by plug-ins, and the same applies to vector graphics
> formats.
>
> --
> Glynn Clements <gl...@sensei.co.uk>
Gregory R. Block
> True, and my guess would be other will try to hobble PGML to do what
> Flash does now. Why not take Flash further in the tools available
> (adding macro and plugin support for example)? Evolve the tools, not
> reinvent the format.
Because flash would need to be modified to...
1) fundamentally change the file format to something self-descriptive and XML based to allow embedding within a
document,
2) fundamentally modify the format and system to correspond to the DOM, and its need to create/delete/modify
entries within the hierarchy,
3) fundamentally change the "timeline" based behavior to an event-driven model.
> I dont understand this comment. Because Flash's source is not available
> for free, then it doesnt matter? Rather, as you state, it doesnt matter
> to the free software community.
That was my point.
> However, its very much in the intrest of
> the free software community to merge mozilla with the appropriate API's
> to handle something like flash as a native file format.
1) Mozilla has all the APIs that it can to let Flash behave under the best of its feature set under the current
Flash architecture.
2) It's flash that needs to be fundamentally altered to support a DOM. Mozilla just needs DOM support. :)
> In concept what you are saying sound great, but the reality is quite
> different. PGML defines very basic shapes..post script like commands.
Yes.
> The fact of the matter is, complex animations are not made out of simple
> shapes. Its not the javascript 1.2 model of moving layers from point 1
> to point 2. Id like to see PGML description of something like what
> spumco does or gabocorp. The file would be huge! It wouldn't be
> practical to put it inside of a client side document.write.
This got mentioned in another thread, but supporting compression types as a part of HTML compression would keep the
filesizes quite a ways down, assuming that the proper compression algorithm was used. (Dictionary management gets
difficult when you're working in small buffer sizes but want to benefit from repeated use across the whole document
without leaving the on-the-fly model.)
> And thats the point here. PGML cant do Flash *easily* as you claim. It
> is at such a lower level of description. It can't claim to do anything
> but simple animations (like moving circles, or boxes, or plotting
> boxes).
PostScript can go beyond moving circles, boxes, and plotting boxes. So can PDF. By default, practically
everything possible within those two page description formats is possible within PGML.
Having said that, PS/PDF aren't compact and efficient.
Oh, and I take back the bit about PGML not supporting streaming; it's certainly possible, so long as you insist
that control information only access PGML structures which have previously appeared in the document.
PGML is missing native transforms support, a native concept of "frames".
It has an equivalent matrix definition and set of primitives, a better hierarchical model, a better object
dictionary,
Flash supports a matrix, color transform, rgba color, string, and multiple shape definition types that define lines
as bezier curves, embedded JPEGs and compressed raw, buttons, fonts, text, ADPCM audio, and "sprites" - embedded
swfs that act as a single swf entity. Actions include placing, removing, and showing an object.
* PGML reuses XML, RDF, CSS, and the DOM. It's innately standards-integrated.
* Many systems already make use of the PS/PDF imaging model in their APIs, which will make rendering simpler.
* Rather than flash's matrix model of bezier sets, PGML uses the PostScript method of object description:
moveto/lineto/curveto/arc/closepath. Therefore, there's more flexibility in shape creation.
* PGML includes primitives.
* PGML includes arbitrary translation matrices with nearly identical functionality to flash.
* PGML supports multiple coordinate systems for placing objects.
* PGML supports several different color models
* PGML supports the Flash "dictionary" through DOM compliant naming.
* PGML supports anti-aliasing, just like Flash
* PGML supports full script embedding
* PGML supports channel opacity via sRGB.
* Supports path-based motion along complex path definitions
* Any PGML object can be given a description, for the visually impaired or for providing labelling.
PGML is *clearly* more based on higher-end vector-based presentation. There's a lot more variation and flexibility
all over it.
What's seriously mising?
* Timeline-based behavior. However, look at Dreamweaver to see how you can implement that in the editor and
provide it as a part of the object. Again, a sizing problem - the "engine" is in the graphic, not the display
technology, which will increase the size. But PGML is a shitload bigger anyways, so size is a problem
regardless.
* Frame-based animations. Streaming Flash is easy, because you can define your objects, eat your control
commands and start doing things while you're grabbing the next frame, and have a concrete idea of what to do
when - PGML is freeform, no frame-based control, and there's no strict demand on when one should and shouldn't
include controls. Streaming PGML is fine, so long as you're streaming a static 2D image, but add animation,
and suddenly the file format isn't actually *helping* you do it, whereas with flash, the definition of the
file format allows easy implementation of the streaming capability.
* You can't embed bitmap graphics or sound.
* No synchronizing for audio/video (that requires scripting)
> So in theory PGML sounds great. Since its all text its easy to generate,
> integrate with a scripting language, and integrate with DOM. But PGML
> simply can't scale to the complexities required in even the most simple
> animations (say a stick figure walking).
Sure it could.
> So why hasnt' DHTML take off? If creating thousand of lines of code in
> javascript just to get something to act like a cdrom experience is so
> easy, then why dont we see these kind of complex 'director' like
> experiences created in DHTML?
Because Director is a completely different beast. Where's the audio/video synchronization in DHTML? Timeline
support? (Timelines are in Dreamweaver)
Dreamweaver is a first whack at creating Director for DHTML. Once the full DOM is supported in browsers, and there
are fewer differences between implementations, Dreamweaver can get a lot more powerful - but there's a lot of
evolution that has to take place.
PGML is not a replacement for Flash - but PGML is far better suited as a general 2D vector system.
> Anyhow, why should anyone have to do that if an easier, friendlier tool
> will create the same thing and better (add sound support, stream, etc).
Because easier and friendlier is not always the issue. Tools that support PGML will be dead easy - why? Because
it's practically PostScript/PDF - which means that there are a whole lot of applications that can do what they do
now and just change syntax in order to output PGML.
> This is back to the tools arguement. You need a great tool to see this
> reality.
No you don't. You can do simple scripting with complex objects pretty simply. If the goal is to take the bitmaps
that are out there now and get more use of drawn objects, PGML will represent those objects better than Flash. If
your goal is to do animations, then Flash is where it's at - because that's its forte.
> i remember a quote from one of the head people of the Dreamweaver team.
> They basically said something like ' well we created dreamweaver because
> we knew there was no possible way to create a GUI tool for every
> possible DHTML type effect...since DHTML is essentially a programming
> language its hard to abstract something so variable'
Absolutely.
> Terrible rephrasing (then again im so bloody tired right now) but the
> point is no tool will ever sophiciatly abstract a programming language
> such as javascript.
Erm. Director. Do remember that all of Director centers around Lingo.
> And THAT my friend, is where we agree ;]
:)
PGML is a more interesting technology to integrate into a browser, because it *lends* itself to integration by so
heavily leveraging XML, RDF, and the DOM.
OTOH, like I said, I think Flash is the bollocks. Gnarly. Wicked. Totally Excellent. I think Macromedia is
doing The Right Thing.
But I'm happy with a Flash plugin. PGML I want native. And not just because it makes better business graphics.
:)
:plur,
Greg
Ben Pennington
I agree as well! What else needs to turned into a plug-in? How about libnet,
libimg and
libfont?
Michael T. Babcock wrote:
> As I wrote to another thread, I agree thoroughly:
>
> Wouldn't it be more useful if a new plug-in API were developed that is more
> seamless?
>
Marc Byrd wrote:
> I agree with your position that even HTML be handled by a plugin. It needn't
> be the case that the html component be ONLY a plugin, and it needn't be the
> case that all of the advanced or generalized layout functionality live in the
> html plugin, but yes, it should be in a plugin.
>
> Along those lines, one of the directions I would like to see is the ability to
> override all internal mimetype handlers (like IMAGE/JPEG , TEXT/HTML, etc.).
> This would allow component development to start, with all of the associated
> benefits (don't have to build the whole mozilla, independent schedules, mix
> and match, consumer choice, etc.). I always joke that it shouldn't take a
> physics geek like me to extoll the benefits of component technology to a bunch
> of c.s. majors ;^).
>
Ben Pennington
Can't we just use SMIL?
Gregory R. Block
> Can't we just use SMIL?
Fascinating point. Revisiting the issues I raised with PGML:
> What's seriously mising?
What's seriously not missing:
> * Timeline-based behavior. However, look at Dreamweaver to see how you can implement that in the editor and
> provide it as a part of the object. Again, a sizing problem - the "engine" is in the graphic, not the display
> technology, which will increase the size. But PGML is a shitload bigger anyways, so size is a problem
> regardless.
Timeline based behavior could be addressed through the use of SMIL due to the use of the DOM within PGML. This could
allow simple presentation-style positioning. Good integration could yield to advanced timeline capabilities much like
those which currently exist in Director.
This does, however, add a considerable level of effort to the implementation of the PGML <animation> tag.
> * Frame-based animations. Streaming Flash is easy, because you can define your objects, eat your control
> commands and start doing things while you're grabbing the next frame, and have a concrete idea of what to do
> when - PGML is freeform, no frame-based control, and there's no strict demand on when one should and shouldn't
> include controls. Streaming PGML is fine, so long as you're streaming a static 2D image, but add animation,
> and suddenly the file format isn't actually *helping* you do it, whereas with flash, the definition of the
> file format allows easy implementation of the streaming capability.
SMIL addresses some of these issues, but not all. In this case, SMIL could provide the core animation capabilities to
the system, but the formats still do not define "frames" with enough precision to *ensure* that streaming would be
possible. It would be up to the generating application to ensure that the XML file was structured in such a way that
dependencies would not cause conflict.
> * You can't embed bitmap graphics or sound.
SMIL doesn't address this. (Surprise. ;)
> * No synchronizing for audio/video (that requires scripting)
SMIL addresses this issue completely, assuming integration with the PGML <animation> tag existed.
Still, between PGML and SMIL, we're talking about a relatively heavyweight solution. Something comparable with
Director and its capabilities; not something which competes with a low-end 2D animation product like Flash, due to the
amount of complexity in the system.
*shrug*
I've probably analysed this whole thing to death, and I apologise if I've bored anyone silly.
:plur,
Greg
Marc Byrd
Michael T. Babcock wrote:
> As I wrote to another thread, I agree thoroughly:
>
> Wouldn't it be more useful if a new plug-in API were developed that ismore
> seamless? Or perhaps move toward using <object> instead of <embed> AND <img>
> ... and all embedded objects, whether handled internally or not would be
> handled by <object> ... then remove "internal" code for handling GIF and JPG
> and make them DLL libraries -- along with any other image format Netscape
> chooses to support. Make the plug-in interface as nice as Adobe Photoshop's
> so that if someone chooses to support PNG better then Netscape (it's not
> hard), they simply make a DLL ... but existing web pages would still work.
> Nothing would get broken that way (distinguishing between <embed> / <object>
> and <img> ...)
>
<EMBED> , <IMG> and <APPLET> are officially deprecated, and <OBJECT> is
definitely the way to go.
With a feature we called anthrax in the mozilla source (setenv ANTHRAX 1), you
can also handle EMBED tags w/ applets - we'll be publishing the whole spec on
that soon. We're also looking at overriding the IMG tag for an installed plugin
or applet registered to the image mimetype(s) - that's blue sky for now. I'll
certainly entertain proposals... (of course working with the imglib folks).
marcb
Marc Byrd
Ben Pennington wrote:
> I agree as well! What else needs to turned into a plug-in? How about libnet,
> libimg and
> libfont?
Methinks Mr. Pennington's tongue is in his cheek...
Actually, this provides an opportunity to discuss the difference between modules and
components (some c.s. major will correct me if I'm using these terms
inappropriately): What Ben has listed here are modules (in my dreams), because
there's one of each of them, a single implementor of a given interface. Plugins are
components, because several of them implement a common, shared interface. The
latter is much more economical when appropriate, because component builders only
have to worry about one end of the interface, not both.
Modules are good, and the XP COM / BAM stuff is going great guns. But by factoring
out components, or providing override capabilities for existing "monolith"
functionality with components, the modularity job is much easier. For example,
consider libnet: if the protocol handlers were componentized via some new
interface, and likewise any stream converters (like gzip decoders), then what would
be left of libnet? Only the essence logic of invoking the correct protocol, tossing
the url off to it, and routing any resulting streams to the appropriate mimetype
handlers. This is much easier to modularize.
This leads to another important illustration: protocol components need not all
implement their own authentication or sockets layers, right? So a three-tier
picture emerges with the bottom layer being the utilities, the second layer being
the protocol components, and the top layer the routing logic. New components are
encouraged but not forced to use the utility layer. In some ways, this reflects the
current plugin architecture, with NPP calls representing calls from the routing
logic into the component, and NPN calls coming from the component to the utilities
layer.
One could imagine a similar utility layer for Images, although the routing logic is
the same as that of plugins (modulo a few badly needed plugin API enhancements such
as palette coordination). Finally, bringing the discussion back to its origin,
Macromedia could (for example) factor certain generalized vector transform and
rendering utilities out of their plugin and into some utility module.
Sabir Hussein
Charles A. Summerhill
To no one in particular:
I don't think this has been mentioned yet, but let us not forget that Flash is
streaming. I haven't read the entire PGML spec, but I don't recall it being a
streaming format (especially if it is embedded in the source of the HTML/XML
document.
My preferences are to go with PGML as it appears to be more extensible (being
based largely on XML). But I think that adding streaming would make it much more
attractive. Although I can also see ways to simulate that feature.
fs...@inamenospam.com
Marc Byrd wrote :
><EMBED> , <IMG> and <APPLET> are officially deprecated, and <OBJECT> is
>definitely the way to go.
Please see the HTML 4.0 spec.
<IMG> is *not* deprecated.
<APPLET> is deprecated.
<EMBED> never existed, so it doesn't need to be deprecated.
FS
Ben Pennington
Honestly, no joking here. You asked my question better than I did and answered it.
I'd like to see a 2D vector graphics plug-in, I just think that it would be nice if
things
like libnet, libimg and libfont were componentized.
Thank you.
John Dowdell
Great thread, thanks. I'll have to print it out so I can absorb it.... ;-)
Just a quick note that, if you have wishes for Flash efforts to take in the
future, then the new Open-SWF newsgroup would be a good place to bring them up.
Brian Dister's on hand for technical assistance, and various Macromedia folks
will be polling that newsgroup for response to the changes.
news://forums.macromedia.com/macromedia.open-swf
Major-league disclaimer: I'm just in tech support at Macromedia, and have no
knowledge of internals or upcoming developments, and just like to see people
reach solutions to problems. Nothing I say should be taken as "official
Macromedia says-this" and so on and so forth.
Anyway, great thread, thanks for the interest, and I'll be looking forward to
studying these posts when I can get 'em on paper.... ;-)
jd
--
John Dowdell, Macromedia Tech Support, San Francisco CA US
Private email options: http://www.macromedia.com/support/priority.html
Search technotes: http://www.macromedia.com/support/search/
Search DIRECT-L: http://www.mcli.dist.maricopa.edu/director/digest/
Newsgroup FAQ: http://www.macromedia.com/support/newsgroups.html
Cross-browser scripting: http://www.dhtmlzone.com/
Michael T. Babcock
Wouldn't it be more useful if a new plug-in API were developed that ismore
seamless? Or perhaps move toward using <object> instead of <embed> AND <img>
... and all embedded objects, whether handled internally or not would be
handled by <object> ... then remove "internal" code for handling GIF and JPG
and make them DLL libraries -- along with any other image format Netscape
chooses to support. Make the plug-in interface as nice as Adobe Photoshop's
so that if someone chooses to support PNG better then Netscape (it's not
hard), they simply make a DLL ... but existing web pages would still work.
Nothing would get broken that way (distinguishing between <embed> / <object>
and <img> ...)
This would lead to Xara, Macromedia, etc. simply tossing "plug-in"-able
functionality into their shipping DLLs ... probably. Xara files would be
supported exactly the way they are in the program, etc.
Glynn Clements wrote:
> This begs the question of whether Mozilla *needs* a `native' vector
> graphics format. Or for that matter whether it needs *any* native file
> formats.
>
> IMHO, this sort of thing should be delegated to a plug-in. Ideally it
> should even be possible to delegate HTML et al to plug-ins.
>
> HTML may be harder, as you would need to be able to have access to all
> of the browser's features, e.g. invoking other plug-ins.
>
> However, I can't see any reason why bitmapped graphics formats can't
> be handled by plug-ins, and the same applies to vector graphics
> formats.
--
_____/~-=##=-~\_____
-=+0+=-< Michael T. Babcock >-=+0+=-
~~~~~\_-=##=-_/~~~~~
http://w3.tyenet.com/mbabcock/ ICQ: 4835018
Michael T. Babcock
like to know is if the plug-in API will be modified at all -- in the way plug-in
makers use it (the API) ... internally I expect it will change to give more
functionality of course.
Marc Byrd wrote:
> <EMBED> , <IMG> and <APPLET> are officially deprecated, and <OBJECT> is
> definitely the way to go.
>
> With a feature we called anthrax in the mozilla source (setenv ANTHRAX 1), you
> can also handle EMBED tags w/ applets - we'll be publishing the whole spec on
> that soon. We're also looking at overriding the IMG tag for an installed plugin
> or applet registered to the image mimetype(s) - that's blue sky for now. I'll
> certainly entertain proposals... (of course working with the imglib folks).
--
Gregory R. Block
> Anyway, great thread, thanks for the interest, and I'll be looking forward to
> studying these posts when I can get 'em on paper.... ;-)
If you find anything you disagree with, feel free to e-mail me. I'm just as
verbose and opinionated in e-mail as I am on newsgroups.
:plur,
Greg
Gregory R. Block
> To no one in particular:
>
> I don't think this has been mentioned yet, but let us not forget that Flash is
> streaming. I haven't read the entire PGML spec, but I don't recall it being a
> streaming format (especially if it is embedded in the source of the HTML/XML
> document.
Actually, I did mention that it streamed.
> My preferences are to go with PGML as it appears to be more extensible (being
> based largely on XML). But I think that adding streaming would make it much more
> attractive. Although I can also see ways to simulate that feature.
I also mentioned that nothing *prevents* PGML from streaming.
The streaming support in flash consists of two "rulesets" imposed by the file
format:
1) Any object must appear in definition before any control/command which operates on
that object.
2) A "frame"-based definition exists, native to the file format, to define a single
event frame.
2) isn't as important as 1) in the case we're referring to, because there's no
inherent timeline-based system that says what the hell you should do with the frames
in 2) in PGML, so we'll separate that.
PGML has some really psychotic things, like wanting to interpret any
document.write() from inside a PGML document inserting into the PGML stream in
situ... That might make streaming difficult, because it could introduce some pretty
strange and unpredictable object dependencies. Mostly, though, streamability is up
to the author (whether it be a tool or a person) to make sure that rule number 1 is
enforced (which is exactly how Macromedia's provides that functionality.)
2) requires timelining. Which isn't a part of PGML, but SMIL could offer, because
PGML objects could be animated by SMIL using the DOM and scripting. So you create
all of your objects in PGML, including all of their behavior, as stand-alone
objects, and then write your behavior in SMIL.
Where that fails is that in Flash, the "timeline" is broken into fragments,
distributed throughout the frameset; whereas, SMIL may or may not be easily
embeddable into PGML; it remains to be seen.
Regardless, they definitely approach the problem from different directions. Flash
is a long way from being a high-detail 2D system based on quality. PGML is a long
way from being a streaming 2D animation system.
:plur,
Greg