OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmopen-members message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: RE: NN fragment -- bad news?


At 12:34 PM 2/6/01 -0600, Greg Gallant wrote:
> > Netscape's lack of concern about the problem is
> > more serious now (because 4.73 is affected, as well
> > as the somewhat shakey new 6.0 release), and I think
> > we need to attack as energetically it as we did IE.
>
>Best of luck here.  They are giving away their product to a captive AOL
>audience of around 30 million users, few of which could give a hoot about
>WebCGM.

Interestingly enough, Microsoft actually put their IE project manager onto 
it, working with us, until it was solved (resulting in the BHO).  I think 
the pressure from US Navy and Boeing helped immensely.  I think they won 
some points by being responsive.

Netscape already said, in the Bugzilla dialog, that "Enterprise clients" 
(Boeing, US Navy) were not their principal focus at this time (in 
development of 6.0).  So we tried the SVG connection -- SVG won't work 
either, as its object addressing is based on fragments just like in 
WebCGM.  Chris Lilley has weighed in on it (in Bugzilla dialog), with 
inconclusive results.

At that time, we thought 4.73 was okay and didn't know about 6.0 -- we were 
trying to diagnose it.  Now that we know the situation, and now that we 
know it affects all NN versions, we need to try to see what we can do in 
the way of either a fix (fix NN, seems unlikely), or workarounds (like the 
BHO).

I'll let others comment on your workaround, below...

> >
> > At 09:19 AM 2/6/01 +0100, Dieter Weidenbrueck wrote:
> > > All,
> > >
> > > I agree with Greg here. However, we still need to be
> > > able to insert a simple HREF pointing to an object
> > > inside a WebCGM file into HTML.  To load a file
> > > explicitely as described by Greg you would always
> > > need a javascript.
>
>For what it's worth, this is really a non-issue.  All commonly-used browsers
>support JavaScript, and the coding difference between a standard HREF and an
>HREF that indirects through a script is small:
>
><A HREF="http://some_name/file.cgm"> Hypertext </A>
>
>versus
>
><A HREF="JavaScript:ShowCGM('http://some_name/file.cgm')"> Hypertext </A>
>
>or
>
><A HREF="#" ONCLICK="ShowCGM('http://some_name/file.cgm')"> Hypertext </A>
>
>Note that the browser "knows" what to do when it sees just the fragment
>separator in the above, commonly used, HREF syntax.  When you ask the
>browser developers to mess with how they are currently handling fragments
>there is a domino effect for code within their product.  They incur a
>serious Q/A cycle.
>
>We recommend that our viewer customers generate links like the above which
>directly end up calling our viewer to load a cgm.  Doing so allows them to
>take advantage of our internal optimizations.  I don't know of any
>complaints about the slight adjustment in syntax.

[LH clarification:  this refers to ActiveCGM, not WebCGM]

>-gcg



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC