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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

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


Subject: Re[4]: [cgmo-webcgm] Ecmascript binding question


Hi Kevin,

I agree with your example, but what I don't understand is why an
ecmascript binding helps.

I think that providing the IDL (which is already available in the
spec) is sufficient.  For strong type binding languages this could be
a problem, but for ecmascript, I don't think so.  I may be wrong but
I'd like for someone to provide me with a technical explanation of why
that is.

For me to write an additional binding on top of the IDL is a
lengthy and tedious process; I'd like to know what are the technical
advantages (if any) of me doing this work at the present time.  On top
of being a lengthy process it means that we'll have to maintain two
documents instead of one (IDL and ecmascript binding).  So if we decide
to change an API, we have two documents to keep in sync.

Regards,

-- 
 Benoit   mailto:benoit@itedo.com


Thursday, August 12, 2004, 1:39:54 PM, Kevin wrote:

KOK> All,
KOK>    I will take a stab at explaining this problem. The reason an ecmascript
KOK> binding must be defined is due to an inherent interface that will exist
KOK> between the plug-in and the other presentation aspects of the application.

KOK> Lets say I am a customer who is writing a presentation application that will
KOK> be distrusted to many end users. My presentation application will utilize
KOK> the WEBCGM DOM, and will be written in ecmascript. However, not all of my
KOK> end users will be using the same WebCGM plug-in, as some will be using
KOK> Product A and some will be using Product B. 

KOK> If there is not a standard ecmascript binding defined, then I will have to
KOK> create two versions of my ecmascript, one for each WebCGM plug-in with its
KOK> own defined ecmascript binding. This is not interoperable at all.

KOK> Kevin 

KOK> -----Original Message-----
KOK> From: Benoit Bezaire [mailto:benoit@itedo.com]
KOK> Sent: Thursday, August 12, 2004 9:58 AM
KOK> To: Ulrich Laesche
KOK> Cc: CGM Open WebCGM TC
KOK> Subject: Re[2]: [cgmo-webcgm] Ecmascript binding question


KOK> Hi Ulrich,

KOK> I'm not 100% sure I understand the question, but here is an attempt to
KOK> answer.

KOK> Applications can be exchanged if they use WebCGM standard API calls.
KOK> They will be exchangeable between viewers that implement the WebCGM
KOK> DOM API.

KOK> If the application uses vendor proprietary APIs, it will not run in
KOK> any other viewer.  All vendors *must* implement the API as per defined
KOK> in the spec.  If a viewer implementation diverges from the spec(ie, changes
KOK> function name, return type, parameter type), it will not be standard
KOK> compliant.





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