RE: [xmlhttprequest2] timeout and JSON
I just read through this thread, and found it really interesting. Figured I would chime in with my opinions, for whatever that's worth. Firstly, let me explain I run a project called flXHR (http://flxhr.flensed.com) which is an XHR clone variant with cross-domain Ajax capability (using invisible flash). It implements an identical API to the regular XHR object, so it can be dropped in as a replacement and should behave quite similarly. So, my interest in this discussion is that I of course want to keep flXHR API compatible (as much as possible) with regular XHR implementations in the browsers. 1. With respect to responseJSON, I think this is a good idea. However, I would just say that I think there's some inefficiency when a single response is translated into binary (IE), XML, JSON, text, etc. Very rarely will a single response be applicable to all those formats. So either the conversion fails for the non-applicable formats, or at least there's some processing time spent needlessly trying to convert to XML when it's not well formed XML in the first place, for instance. Perhaps the implementations already take care of this by first validating if a block of text can in fact be converted to that type. But again, even this check must take some processing time. The other thing to consider is how these properties are represented during readyState=3. Text based representation (and even binary) is probably not an issue, but I'm sure that there's got to be some sort of special processing to represent the responseXML as a well formed (auto-node-completed?) XMLdocument when it's only partially downloaded. The same issue would apply to creating a partial JSON object. And I'm not sure how expensive such logic is. Just thinking maybe to avoid some of that, these properties could be on-demand in some way, so that the object doesn't try to do the conversion until it's requested... requires them to be implemented as accessors rather than actual properties, but maybe it would help? Just something to consider. 2. With respect to ontimeout event. I implemented this in flXHR (seeing that IE8 was going to support it), but it looks like I inadvertently took a slightly different take on it (since IE8 was still in early beta when I did flXHR originally). In my opinion, the timeout event is more appropriately applicable in the period of time before any response has been returned (between state 2 and 3/4). Once some response has come back (all or partial), it seems like the timeout is less important/applicable. Maybe this is just opinion and may differ with a lot of different people. But if ontimeout were defined to only fire if the timeout happens before any part of the response comes back, all the questions raised about what to do with the partially filled properties (empty them, reset, abort, etc) would be moot. That's how my ontimeout works. But now that I realize it diverges from IE8's implementation, I may need to revisit it, unless you agree that it's a simpler, better way to approach the timeouts. Certainly, I will follow this discussion more closely to see the outcomes. Thanks for your time and consideration on my opinions. --Kyle Simpson
Re: Comments on Widgets spec
Le mercredi 08 juillet 2009 à 15:20 +0200, Marcos Caceres a écrit : I'm mostly satisfied, but see a few comments below. I'm now satisfied, thanks. Dom
Re: A+E todo
Hi y'all, an update on these todo items: On Jun 29, 2009, at 18:46 , Robin Berjon wrote: - viewMode needs to refer to Widgets-WM. Can we agree on what we need to FPWD that one so that there's something to point to? Does no one have an opinion on this? - locale doesn't make much sense: it's a DOMString that is set to the value of user agent locales, which is an array. Our current algorithm wouldn't allow us to pick one, so it could either be a string joining all of those (as in HTTP) or a sequenceDOMString. But I'm not at all convinced that this is useful and I recommend dropping it. Dropped. - for width and height we should be clearer on what is meant by viewport Done, by adding a definition that maps it to CSS viewports. - preferences needs to be finalised Done, following Hixie's suggestions. - onmodechange shouldn't be Function, it should be ModeChangeEvent, and ModeChangeEvent should have [Callback=FunctionOnly] Done (as ModeChangeListener, of course), along with an explanation of the reason it is expressed that way and an indication that for Javascript it's just a Function. - showNotification() needs a better definiion I'd fix it but I don't really understand what it's expected to do. It appears to be some form of device-independent, asynchronous alert. I don't know if the use case is very strong, but I'm willing to be convinced as alert() is indeed bad for a number of things. I look at the Opera docs since that's where it comes from but they're not clearer than the specification. If the above is indeed what it is supposed to be, I can scare up some text explaining it, but we'd need to at least know what happens if the alert() is cancelled (in most windowing systems you can cancel an alert without hitting Ok, typically Esc does it). Is the callback called? Or is it ignored? Or called with a special value? -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
[widgets] Draft Minutes from 9 July 2009 Voice Conf
The draft minutes from the July 9 Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/07/09-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 30 July 2009 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 09 Jul 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/0144.html See also: [3]IRC log [3] http://www.w3.org/2009/07/09-wam-irc Attendees Present Art, Josh, Robin, Mike, Marcos, Henri, Benoit, AndyB Regrets Marcin Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]PC spec: LC Comment #2233 4. [8]PC spec: Comments status and Next Steps 5. [9]AE spec: plan for LCWD publication 6. [10]WARP spec: plan for LCWD publication 7. [11]Widgets Updates spec: 8. [12]AOB * [13]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Date: 9 July 2009 darobin hsivonen: you gonna join? hsivonen I can call in please do Marcos_ yep darobin easy to tell darobin I can hear the trolls echoing behind you hsivonen that's me Review and tweak agenda AB: agenda posted July 8 ( [14]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/01 44.html ). One change is to drop 3.a. (Francois' comments) and add LC Comment #2233 from Josh ( [15]http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-2 0090528/2233 ). Any other change requests? ... I note Henri is here [14] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/0144.html [15] http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-20090528/2233 darobin new TODO for A+E: [16]http://www.w3.org/mid/1b5ee78b-5fa5-472b-9250-aaade4a09...@berjo n.com [16] http://www.w3.org/mid/1B5EE78B-5FA5-472B-9250- aaade4a09...@berjon.com AB: he says he is representing himself and NOT Mozilla MS: during AOB want to talk about Team Contact going forward Announcements AB: Reminder there will be no widgets call on July 16, July 23 and Aug 6. Any other short announcements? PC spec: LC Comment #2233 AB: LC Comment #2233 ( [17]http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-2 0090528/2233 ) is from Josh. This is the only comment where the Commentor has indicated the group's response is not acceptable. We have an obligation to try to reach consensus so we will start there. ... Josh, would you please briefly clarify for whom you speak re your objection to the group's proposal? [17] http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-20090528/2233 JS: I can't formally speak for Nokia and I can't formally speak for Mozilla ... so I can say I speak for myself ... but I have talked to other people that agree with position AB: I want to clearly understand the current model and the objections Josh and Henri have to it ... Marcos, would you please briefly summarize the issue? MC: the essence of the issue ... the current model is too flexible ... my understand is JS and HV think the flexibilily should be restricted hsivonen For the record, I'm not objecting to anything AB: please, everyone add to the minutes if something is missing ... Josh, do you agree with MC's summary? JS: yes, I do agree ... one issue is how to choose the lang ... another is what to do with the pkg ... the pkg fallback flexibility is too much ... and think user will be surprised by results AB: what is the issue for the pkg creator? JS: I've had some discussions off list and some of that is not part of Public record ... but I will illustrate via an example [ Josh looks for a log of offlist discussions ... ] timeless_mbp ok... a german company creates a package for a company in Switzerland timeless_mbp the package is therefore originally in German (de) timeless_mbp they also then translate it into Italian (as some portion of Switzerland speaks Italian) timeless_mbp and then they translate it into French (... for the same reason) timeless_mbp they also commission for someone to translate it into English timeless_mbp the German company then proceeds to create an updated version which adds additional resources (pictures) timeless_mbp yes timeless_mbp pictures with text timeless_mbp for reference, Nokia uses Flash for its Text :) timeless_mbp sorry... the updated version
Re: [widgets] PC, outstanding feedbac...
All, During the Widget group's July 9 conference call, we discussed Josh's concern and the agreement was to record the concern and to continue with the current model. The minutes from that discussion are at [1]. -Regards, Art Barstow [1] http://www.w3.org/2009/07/09-wam-minutes.html#item03 On Jul 8, 2009, at 9:51 AM, ext Marcos Caceres wrote: For the sake of the DoC, can you live with the current i18n model? On Sun, Jul 5, 2009 at 12:45 AM, timelesstimel...@gmail.com wrote: On Fri, Jul 3, 2009 at 7:35 PM, Marcos Caceresmarc...@opera.com wrote: I talked to our localization guys about this, they said that is definitely not a good thing. They said any content is better than no content, even if there is a mismatch. I've spoken w/ coworkers recently, and other people too, and the general spirit is if the app is so poorly localized, and it usually is, they'd rather see it in the language where it isn't poorly localized that they actually understand (typically English; the people in question are typically natives of Finland and surrounding countries and have have English as at best a second or often a third language) I suspect that in the end, as long as a user agent allows the user to see which localizations the widget has and for the user to express a more limited list of preferences for a given widget, this won't be a problem, and hopefully user agents will do this. I agree, but that is Apple's fault. Yes, the model allows things like this to happen. But I think it's better thank getting no license at all. I still feel that this is an author-level error. I don't like enabling authors to screw up localization, it's too easy to do already, and they've proven to be quite adapt at it locally. -- My experiences in the States didn't show these problems, but that's probably because I was being sold untranslated goods or goods by vendors who were more careful. I agree this sucks, but like I said, my preference is to have something shown. When authors make such mistakes, then can easily be patched via updates, which is what updates are for. The iTunes example is unfixed to this day, a number of updates later. As is Nokia's flags example [1] and Centre (I got an update last week). I agree. But again, iTunes should do something about that. It can't be the case that widgets would not allow me to ship a widget because I can't get something translated. If that was the case, I would still include the wrongly localized content just so I could ship I'd prefer for you to be aware that you're screwing your customer. Having to actively jump through a hoop This is wrong, but I'm desperate and in a hurry, and know it's wrong v. I'm done, it's perfect, I'm never making any changes ever again (and just say, centre, center, meh! Only a few will notice, so I'll fix that in the next update.). Bah, it's still not fixed, and I've complained both through the care number and internal feedback. [1] http://library.forum.nokia.com/index.jsp?topic=/ Web_Developers_Library/GUID-63F29096-C1A3-45DB-9E2F-6110562E0237.html It's good to see no one fixes their bugs. I really look forward to widget updates being as useless as everyone else's updates in these areas. -- Marcos Caceres http://datadriven.com.au
[WIDGET URI] i18n comment 1: URI Spec
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-uri-20090618/ Comment 1 At http://www.w3.org/International/reviews/0907-widgets/ Editorial/substantive: S Tracked by: AP Location in reviewed document: - Comment: We second Martin's comments at http://lists.w3.org/Archives/Public/public-i18n-core/2009AprJun/0067.html. The term URI appears to mean URI and *not* IRI universally here. No non-ASCII paths are given in examples and the relationship to IRI is not specified. The Packaging and Configuration spec mentions encodings and permits the full range of Unicode in file names, so the lack of specificity is at least an oversight. I suspect that, depending on the use of the URI, they really do mean IRI here, though. Packaging and Configuration strongly suggests the use of the UTF-8 encoding for Zip relative paths and human-readable (native encoded) URIs would be more in keeping with the usability desires of web-apps.
[WIDGET PC] i18n comment 1: Wrong language tag.
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 1 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 7.2 [http://www.w3.org/TR/2009/WD-widgets-20090528/#examples] Comment: The simple example in Section 7.2 still contains an error. The language tag for Spanish is es, not sp. It is shown correctly in the graphic but not the title of the section or elsewhere in the text.
[WIDGET PC] i18n comment 3: Widget metadata
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 3 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 8.3 [http://www.w3.org/TR/2009/WD-widgets-20090528/#attribute-types] Comment: The widget metadata does successfully incorporate our comments that multiple languages should be allowed on those attributes that make sense with them.
[WIDGET PC] i18n comment 4: Various positive observations
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 4 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 8.3 [http://www.w3.org/TR/2009/WD-widgets-20090528/#attribute-types] Comment: its:dir appears in this document and is a good illustration of its proper use, as does xml:lang. See, for example, section 8.8. The 'charset' attribute appears in the element content and appears to be properly specified The its:span element appears in the document and appears to be properly specified.
[WIDGET PC] i18n comment 6: Use of its:dir
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 6 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 9.1, step 5 [http://www.w3.org/TR/2009/WD-widgets-20090528/#step-5--derive-the-user-agents-locale] Comment: its:dir appears in this document and is a good illustration of its proper use, as does xml:lang. See, for example, section 8.8.
[WIDGET PC] i18n comment 5: Too small arbitrary limit on locale ids
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 5 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: S Tracked by: AP Location in reviewed document: Section 9.1, step 5 [http://www.w3.org/TR/2009/WD-widgets-20090528/#step-5--derive-the-user-agents-locale] Comment: In Step 5 of section 9.1, we find an arbitrary limit on locale identifiers (BCP 47 language tags): Each item in the unprocessed locales must be a string shorter than eight characters, in lowercase form, that conforms to the production of a Language-Tag, as defined in the [BCP47] specification. This limit is too short for even some simple language tags. Consider zh-Hant-CN, which is given as an example in the document: it has 10 characters. This limit really should be removed. The eight character limit is on subtags.
[WIDGET PC] i18n comment 2: Clarify IRI/URI
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 2 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 8.3 [http://www.w3.org/TR/2009/WD-widgets-20090528/#attribute-types] Comment: Section 8.3 (Attribute Types) contains a subsection called URI Attribute which is relevant to our comment above. It says: -- An attribute defined as containing a valid URI. A valid URI is one that matches the URI token of the [URI] specification or the IRI token of the [RFC3987] specification. The value of this kind of attribute is retrieved using the rule for getting a single attribute value. -- This is problematical, since all URIs are IRIs, but not the converse. We think this should favor IRI and note the relationship to URI.
[WIDGET PC] i18n comment 7: Step not necessary?
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 7 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 9.1, step 4 [http://www.w3.org/TR/2009/WD-widgets-20090528/#step-4--locate-and-process-the-digital-s] Comment: In this same step, substep 4 is unnecessary. It does save processing time, but it is not required for proper operation. Performing the specific change suggested also has the negative side-effect of altering the user's preferences ahead of the local configuration. The rightmost occurrence would be a better choice for elimination.
Re: [WIDGET URI] i18n comment 1: URI Spec
On Jul 9, 2009, at 21:15 , ish...@w3.org wrote: I suspect that, depending on the use of the URI, they really do mean IRI here, though. Yes, that is correct. It's a quick oversight largely due to simplemindedly using URI throughout because it's in the specification's name. It'll be fixed in the next draft. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
[widgets] Late comments for the 28 May 2009 LCWD of Packaging and Configuration spec
Richard, All, Even though June 19 was the deadline for comments for the PC LCWD, we welcome comments for that document at any time. I created the following document to track late comments and added the seven comments Richard sent today: http://www.w3.org/2008/webapps/wiki/Widgets/PandC-LCWD-28May2009 Note we agreed during our July 2 voice conference [1] that late comments will not be added to this LCWD's Comment Tracking Document [2]. -Regards, Art Barstow [1] http://www.w3.org/2009/07/02-wam-minutes.html#item03 [2] http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-20090528/ Begin forwarded message: From: ext ish...@w3.org ish...@w3.org Date: July 9, 2009 3:07:51 PM EDT To: public-Webapps@w3.org public-Webapps@w3.org, public-i18n- c...@w3.org public-i18n-c...@w3.org Subject: [WIDGET PC] i18n comment 1: Wrong language tag. Archived-At: http://www.w3.org/mid/ 20090709190753.861ec4e...@homer.w3.org Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 1 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 7.2 [http://www.w3.org/TR/2009/WD-widgets-20090528/#examples] Comment: The simple example in Section 7.2 still contains an error. The language tag for Spanish is es, not sp. It is shown correctly in the graphic but not the title of the section or elsewhere in the text.
Re: Web IDL syntax
Hi,
Any other vestiages from the past in the IDL that seems ripe for change?
'InterfaceInheritance' is currently defined as a ScopedNameList or
epsilon. But in practice I don't see any web interface that actually
uses the multiple interface inheritance like,
interface X : A, B, C
{
}
Is it possible to inhibit the multiple interface inheritance at the
Web IDL grammar level? Now that we have ImplementedOn or 'implements',
the multiple interface inheritance seems to be unnecessary to me.
Best,
- Shiki
On Fri, Jun 19, 2009 at 1:54 PM, Cameron McCormackc...@mcc.id.au wrote:
Hello WG.
I’m thinking about removing some of the extended attributes in Web IDL
and replacing them with non-extension syntax in the language.
Originally, I had a goal of keeping compatibility with OMG IDL, which is
why many features currently require extended attributes. Upon
reflection, I don’t think compatibility with OMG IDL syntax is a useful
goal, especially when it gets in the way of neatly specifying particular
requirements.
So if we are happy to extend the IDL syntax, I think any extended
attribute that is intended to have some effect across all language
bindings should be moved to the syntax proper. Following are my half
baked proposals. I haven’t them through much; comments very much
welcome.
Thanks,
Cameron
Changes to extended attributes
--
[Callable]
Callable objects would be specified using an operation-like syntax.
interface NumberQuadrupler {
callable float compute(in float x);
};
Would mean that in languages where objects can be callable,
NumberQuadruplers would be callable, but wouldn’t have a method called
“compute”. Languages that do not support callable objects would have
the “compute” method.
You would also be able to specify a separate callable:
interface NumberQuadrupler {
callable float (in float x);
};
where for langauges that don’t support callable objects, there wouldn’t
be any method on NumberQuadrupler objects.
[Constructor]
I’d say to keep this as an extended attribute, but make it be
ECMAScript-specific. If factory methods are required across language
bindings, then explicit factory interfaces should be written.
[ExceptionConsts]
This should be dropped, and instead the IDL syntax would allow constants
to be specified on exceptions directly.
module fileio {
exception FileIOException {
const unsigned short FILE_NOT_FOUND = 1;
const unsigned short READ_ERROR = 2;
const unsigned short WRITE_ERROR = 3;
unsigned short code;
};
};
[ImplementedOn]
I’d like to take up Ian’s suggestion
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0362.html
of syntax to specify when objects implementing interface A always
implement interface B.
Instead of having:
[ImplementedOn=Node]
interface EventTarget {
…
};
you would have:
interface EventTarget {
…
};
Node implements EventTarget;
and for the reverse case, where Anne requested an [Implements] extended
attribute
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0360.html
you would have:
interface XMLHttpRequestUpload {
…
};
XMLHttpRequestUpload implements EventTarget;
Note that using interface inheritance is slightly different from this
“implements” syntax, since the former makes particular requirements of
the prototype chain in ECMAScript and the actual inheritance hierarchy
in Java.
[{Index,Name}{Creator,Deleter,Getter,Setter}]
As with the “callable” keyword, indexing operations would be specified
with operation-like syntax.
interface OrderedMap {
readonly attribute unsigned size;
getter any getByIndex(in unsigned long index);
setter void setByIndex(in unsigned long index, in any value);
deleter void removeByIndex(in unsigned long index);
getter any get(in DOMString name);
creator setter void set(in DOMString name, in any value);
deleter void remove(in DOMString name);
};
As with “callable”, the “getter”, “creator”, “setter” and “deleter”
modifiers on an operation indicate that if the language binding supports
object indexing like this, the methods won’t exist. To have a getter
that exists in ECMAScript while also keeping the method, you’d do:
interface HTMLCollection {
…
Element item(in unsigned long index);
getter Element (in unsigned long index);
…
};
An alternative would be to reverse the omission of methods, so that
“getter” on an operation would always have both the getter. Then if you
wanted to omit the method if getters are supported you could do
something like:
interface DOMStringMap {
omittable getter DOMString get(in DOMString name);
omittable setter void set(in DOMString name, in DOMString value);
…
};
and getters/setters defined with no operation name would be implicitly
omittable.
Not sure which of the above two ways is better, at the
Re: Web IDL syntax
Shiki Okasaka:
'InterfaceInheritance' is currently defined as a ScopedNameList or
epsilon. But in practice I don't see any web interface that actually
uses the multiple interface inheritance like,
interface X : A, B, C
{
}
SVG does:
http://dev.w3.org/SVG/profiles/1.1F2/publish/idl.html
Admittedly this isn’t Web IDL, still OMG IDL.
Is it possible to inhibit the multiple interface inheritance at the
Web IDL grammar level? Now that we have ImplementedOn or 'implements',
the multiple interface inheritance seems to be unnecessary to me.
There is a subtle difference between ‘implements’ and multiple
inheritance. In Java, ‘interface X : A, B, C’ will result in a Java
interface that looks like
public interface X extends A, B, C {
}
while having
interface X { };
X implements A;
X implements B;
X implements C;
will just correspond to
public interface X {
}
and all X objects will happen to implement A, B and C.
In ECMAScript there is no difference.
Also note that I’ve dropped [ImplementedOn] in favour of the
‘implements’ statement, although I notice just now that there are still
a couple of references to it that I need to remove.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL syntax
SVG does:
http://dev.w3.org/SVG/profiles/1.1F2/publish/idl.html
Admittedly this isn’t Web IDL, still OMG IDL.
I see. Thanks Cameron. So even though it seems those can be replaced
by 'implements', is it not a plan?
- Shiki
On Fri, Jul 10, 2009 at 12:23 PM, Cameron McCormackc...@mcc.id.au wrote:
Shiki Okasaka:
'InterfaceInheritance' is currently defined as a ScopedNameList or
epsilon. But in practice I don't see any web interface that actually
uses the multiple interface inheritance like,
interface X : A, B, C
{
}
SVG does:
http://dev.w3.org/SVG/profiles/1.1F2/publish/idl.html
Admittedly this isn’t Web IDL, still OMG IDL.
Is it possible to inhibit the multiple interface inheritance at the
Web IDL grammar level? Now that we have ImplementedOn or 'implements',
the multiple interface inheritance seems to be unnecessary to me.
There is a subtle difference between ‘implements’ and multiple
inheritance. In Java, ‘interface X : A, B, C’ will result in a Java
interface that looks like
public interface X extends A, B, C {
}
while having
interface X { };
X implements A;
X implements B;
X implements C;
will just correspond to
public interface X {
}
and all X objects will happen to implement A, B and C.
In ECMAScript there is no difference.
Also note that I’ve dropped [ImplementedOn] in favour of the
‘implements’ statement, although I notice just now that there are still
a couple of references to it that I need to remove.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL syntax
Shiki Okasaka: I see. Thanks Cameron. So even though it seems those can be replaced by 'implements', is it not a plan? They could be replaced with ‘implements’, but not without breaking Java bindings. Existing code that compiles against the SVG 1.1 interfaces might not compile against them if converted to use ‘implements’. So it’s not my plan to remove multiple inheritance at the moment, no. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [webworkers] Tasks
On Thu, 11 Jun 2009, Anne van Kesteren wrote: On Thu, 11 Jun 2009 23:39:15 +0200, Ian Hickson i...@hixie.ch wrote: On Tue, 26 May 2009, Anne van Kesteren wrote: Also it is not clear whether Web Workers reuses the generic task sources defined in HTML5 or whether it has any task sources at all, for that matter. Each task queue has one or more task sources, so yes. Sure, but which task source is used in Web Workers when a task is queued? Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
