Re: [whatwg] Java language bindings for HTML5
On Mon, 17 May 2010, Kühn Wolfgang wrote: I was wondering if there are any precompiled Java language bindings for HTML5? There's nothing official; hopefully the links provided by other people on this thread are helpful though. As it is, i can't figure package names, for example for the WebSocket API. According the WebIDL specs, it should be org.w3c.WebSocket, right? As for the html5 elements, will there be a new package org.w3c.dom.html5? All the DOM stuff should end up in the same package, but I'm not sure what that is. That's probably binding-specific. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Java language bindings for HTML5
On Fri, May 21, 2010 at 9:09 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/21/10 1:34 AM, Shiki Okasaka wrote: * backward binary compatibility: the application programs developed with the former SDKs should run with browsers as long as browsers retain the required features for ECMAScript. Gecko has this now for DOM interfaces, mostly. It's a noticeable performance and memory penalty, especially as features need to be added, due to the way it's implemented right now on top of C++ vtables. As Benjamin mentioned, we will most likely stop doing this by default for the core DOM interfaces. Someone could still provide a stable ABI in some form of C++ binding, but it's not clear to me that we plan to do that ourselves. Patches accepted, probably. Thanks for the comment, Boris. I guess a solution would be somewhere between the ABI like this one and NPAPI. Have you blogged about new ideas? If so, I would appreciate the pointers. - Shiki -Boris
Re: [whatwg] Java language bindings for HTML5
On 5/21/10 1:34 AM, Shiki Okasaka wrote: * backward binary compatibility: the application programs developed with the former SDKs should run with browsers as long as browsers retain the required features for ECMAScript. Gecko has this now for DOM interfaces, mostly. It's a noticeable performance and memory penalty, especially as features need to be added, due to the way it's implemented right now on top of C++ vtables. As Benjamin mentioned, we will most likely stop doing this by default for the core DOM interfaces. Someone could still provide a stable ABI in some form of C++ binding, but it's not clear to me that we plan to do that ourselves. Patches accepted, probably. -Boris
Re: [whatwg] Java language bindings for HTML5
On Thu, May 20, 2010 at 3:38 AM, Benjamin Smedberg benja...@smedbergs.us wrote: On 5/19/10 5:41 AM, Kühn Wolfgang wrote: C++ WebCore.html.HTMLCanvasElement (WebKit) dom.nsIDOMHTMLCanvasElement (Firefox) Mozilla nsI* interfaces, if they continue to exist, should be treated as internal. We have little interest in binding to a frozen interface definition. The interfaces may change or be extended in the future. I agree browser's internal definitions are not good examples here, and frozen interface definitions are not very interesting. For the static programming languages which are trying to support the Web platform, I think the following characteristics would be necessary: * frequent SDK updates: the SDK should keep catching up with browsers quickly as they support new, updated Web specifications. * backward binary compatibility: the application programs developed with the former SDKs should run with browsers as long as browsers retain the required features for ECMAScript. - Shiki --BDFS
Re: [whatwg] Java language bindings for HTML5
On Tue, May 18, 2010 at 3:27 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 18 May 2010 04:38:21 +0200, Shiki Okasaka sh...@google.com wrote: On Mon, May 17, 2010 at 6:27 PM, Kühn Wolfgang wo.ku...@enbw.com wrote: Hi, As for the html5 elements, will there be a new package org.w3c.dom.html5? This is our concern, too. Historically each W3C specification introduced its own module name. However, the recent specifications tend to omit the module specification in the IDL definition. cf. http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1380.html In the IDL files we used above, we chose module names that seem to be practical, but those are not part of the standard. Hopefully more people will revisit this issue sometime soon. Can't they all just use org.w3c.dom? We cannot make the interface names overlap anyway. I think one module name for all of the Web platform would work fine for programming languages joining to the Web platform only recently. But for languages like Java, I guess it would be nice to have a rule for obtaining module names. I'm curious how directory name (cssom, workers, postmsg, etc.) is assigned for each specification today. Can we use the same name as a module name in most of the cases? It wouldn't work for cssom, cssom-vew, though. - Shiki -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Java language bindings for HTML5
On Wed, 19 May 2010 08:40:16 +0200, Shiki Okasaka sh...@google.com wrote:
On Tue, May 18, 2010 at 3:27 PM, Anne van Kesteren ann...@opera.com
wrote:
Can't they all just use org.w3c.dom? We cannot make the interface names
overlap anyway.
I think one module name for all of the Web platform would work fine
for programming languages joining to the Web platform only recently.
But for languages like Java, I guess it would be nice to have a rule
for obtaining module names.
I'm curious how directory name (cssom, workers, postmsg, etc.) is
assigned for each specification today. Can we use the same name as a
module name in most of the cases? It wouldn't work for cssom,
cssom-vew, though.
Usually the WG working on the specifications comes up with a shorthand and
proposes this to the W3C Team. Very ad-hoc. But they are unique in a way
so I suppose they could be used. The thing I would like to avoid is having
to put module {} around most interface definitions because it is not
useful for most of the target audience.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Java language bindings for HTML5
Hi, In the future, I see a lot of libraries soft-implementing WebIDL interfaces without binding against a standard interface, may it be Java, C# or C++. This is not good for many reasons. The most obvious are that consumers cannot exchange implementations, and that implementors have no tool support to check the conformance of their implementation. A quick search reveals the following implementations for the HTML5 Canvas Element alone: Java com.googlecode.gwt.graphics2d.client.canvas.HTMLCanvasElement com.google.gwt.gears.client.canvas.Canvas com.google.gwt.corp.gfx.client.canvas.CanvasElement gwt.g2d.client.graphics.canvas.CanvasElement gwt.ns.graphics.canvas.client.Canvas C++ WebCore.html.HTMLCanvasElement (WebKit) dom.nsIDOMHTMLCanvasElement (Firefox) Other static typed languages org.milescript.canvas.HTMLCanvas dom.HTMLCanvasElement (esidl) com.w3canvas.ascanvas.HTMLCanvasElement com.googlecode.flashcanvas.Canvas Agreeing on a name space does have far reaching consequences, as the example of org.w3c.dom.html.HTMLImageElement in DOM Level 1 shows. Because of a subtle change in the api the w3c chose to rename the package to org.w3c.dom.html2.HTMLImageElement in DOM Level 2. However, some 8 years later, the JRE only ships with org.w3c.dom.html, and the xerces DOM implementation and HTML parser do only support Level 1. Web-centric use cases for implementing in static typed languages are * UA implementations such as WebKit or Gecko * Cross-compiling to JavaScript (for example GWT) * Automating browsers for testing and debugging Greetings, Wolfgang -Ursprüngliche Nachricht- Von: Shiki Okasaka [mailto:sh...@google.com] Gesendet: Mittwoch, 19. Mai 2010 05:22 An: Kühn Wolfgang Cc: Anne van Kesteren Betreff: Re: [whatwg] Java language bindings for HTML5 Hi Kühn, I think this is a very good point. Would you mind sending this to wha...@lists.whatwg.org? I wonder if we apply this rule to HTML5, what will be the likely module name for HTML today; html5, html101, or html2010? Any guesses? The interface versioning is a very important topic for the static languages like Java, C++. But I guess this would be mainly the problem of the programming language side; since HTML is growing very rapidly these days, and browsers often implement draft specifications, we cannot simply wait for the drafts become the recommendations. I'm very interested in what would be the best way to dealing with that with the static languages. Best, - Shiki On Tue, May 18, 2010 at 7:25 PM, Kühn Wolfgang wo.ku...@enbw.com wrote: Hi, addition is possible. Modification is a problem. For example there was a change in the semantic of HTMLImageElement from DOM Level 1 to Level 2: org.w3c.dom.html.HTMLImageElement String getHeight() org.w3c.dom.html2.HTMLImageElement int getHeight() These two definitions are not compatible and must be in different namespaces. Greetings, Wolfgang -Ursprüngliche Nachricht- Von: Anne van Kesteren [mailto:ann...@opera.com] Gesendet: Dienstag, 18. Mai 2010 08:28 An: Kühn Wolfgang; Shiki Okasaka Cc: whatwg@lists.whatwg.org Betreff: Re: [whatwg] Java language bindings for HTML5 On Tue, 18 May 2010 04:38:21 +0200, Shiki Okasaka sh...@google.com wrote: On Mon, May 17, 2010 at 6:27 PM, Kühn Wolfgang wo.ku...@enbw.com wrote: Hi, As for the html5 elements, will there be a new package org.w3c.dom.html5? This is our concern, too. Historically each W3C specification introduced its own module name. However, the recent specifications tend to omit the module specification in the IDL definition. cf. http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1380.html In the IDL files we used above, we chose module names that seem to be practical, but those are not part of the standard. Hopefully more people will revisit this issue sometime soon. Can't they all just use org.w3c.dom? We cannot make the interface names overlap anyway. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Java language bindings for HTML5
On 5/19/10 5:41 AM, Kühn Wolfgang wrote: C++ WebCore.html.HTMLCanvasElement (WebKit) dom.nsIDOMHTMLCanvasElement (Firefox) Mozilla nsI* interfaces, if they continue to exist, should be treated as internal. We have little interest in binding to a frozen interface definition. The interfaces may change or be extended in the future. --BDFS
Re: [whatwg] Java language bindings for HTML5
On Tue, 18 May 2010 04:38:21 +0200, Shiki Okasaka sh...@google.com wrote: On Mon, May 17, 2010 at 6:27 PM, Kühn Wolfgang wo.ku...@enbw.com wrote: Hi, As for the html5 elements, will there be a new package org.w3c.dom.html5? This is our concern, too. Historically each W3C specification introduced its own module name. However, the recent specifications tend to omit the module specification in the IDL definition. cf. http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1380.html In the IDL files we used above, we chose module names that seem to be practical, but those are not part of the standard. Hopefully more people will revisit this issue sometime soon. Can't they all just use org.w3c.dom? We cannot make the interface names overlap anyway. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Java language bindings for HTML5
Hi, I was wondering if there are any precompiled Java language bindings for HTML5? Earlier specs had them included, for example http://www.w3.org/TR/DOM-Level-3-Core/java-binding.htmlbinding.html Are there any tools to generate Java interfaces from WebIDL? As it is, i can't figure package names, for example for the WebSocket API. According the WebIDL specs, it should be org.w3c.WebSocket, right? As for the html5 elements, will there be a new package org.w3c.dom.html5? Many greetings, Wolfgang Kuhn - IT-Strategie Prozesse Office: +49 (0) 721 63 15480 Mobile: +49 (0) 160 97621841 Durlacher Allee 93 76131 Karlsruhe EnBW Trading GmbH Sitz der Gesellschaft: Karlsruhe Handelsregister: Amtsgericht Mannheim ‑ HRB 108013 Geschäftsführer: Ralf Klöpfer, Dr. Dirk Mausbeck
Re: [whatwg] Java language bindings for HTML5
Hi, On Mon, May 17, 2010 at 6:27 PM, Kühn Wolfgang wo.ku...@enbw.com wrote: Hi, I was wondering if there are any precompiled Java language bindings for HTML5? The Java files generated from a set of Web IDL files with our esidl Web IDL compiler are available at, http://es-operating-system.googlecode.com/files/java-binding.1714.zip This zip file contains ###_Constructor interfaces, but those are only our experimental ones. The W3C specifications used for this are summarised at the end of this page, http://code.google.com/p/es-operating-system/wiki/CplusplusDOM Note this page describes about C++ bindings, but esidl can generate Java bindings, too. Earlier specs had them included, for example http://www.w3.org/TR/DOM-Level-3-Core/java-binding.htmlbinding.html Are there any tools to generate Java interfaces from WebIDL? To use esidl, please install bison, yacc, and ant, then follow the steps below: $ mkdir esidl $ svn checkout http://es-operating-system.googlecode.com/svn/trunk/esidl src $ mkdir obj $ cd obj $ ../src/configure $ make $ cd java $ ant This leaves .java and .class files under esidl/obj/java/org/w3c/. As it is, i can't figure package names, for example for the WebSocket API. According the WebIDL specs, it should be org.w3c.WebSocket, right? As for the html5 elements, will there be a new package org.w3c.dom.html5? This is our concern, too. Historically each W3C specification introduced its own module name. However, the recent specifications tend to omit the module specification in the IDL definition. cf. http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1380.html In the IDL files we used above, we chose module names that seem to be practical, but those are not part of the standard. Hopefully more people will revisit this issue sometime soon. FYI, public-script-co...@w3.org would be a good place to discuss about Web IDL specific issues. Best, - Shiki Many greetings, Wolfgang Kuhn - IT-Strategie Prozesse Office: +49 (0) 721 63 15480 Mobile: +49 (0) 160 97621841 Durlacher Allee 93 76131 Karlsruhe EnBW Trading GmbH Sitz der Gesellschaft: Karlsruhe Handelsregister: Amtsgericht Mannheim ‑ HRB 108013 Geschäftsführer: Ralf Klöpfer, Dr. Dirk Mausbeck
