RE: Minor comments on Widgets
Hi, One more minor note. In the grammar in section 5.3, you have: low-alpha = %x61-71 I suspect you mean for this to be: low-alpha = %x61-7a thanks, Addison Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs) Internationalization is not a feature. It is an architecture. > -Original Message- > From: Phillips, Addison > Sent: Tuesday, March 15, 2011 8:41 AM > To: 'public-webapps@w3.org' > Cc: 'public-i18n-c...@w3.org' > Subject: Minor comments on Widgets > > Hello Webapps WG, > > (these are personal comments) > > I happened to be referring to the Widget spec this morning and noticed a few > minor items that I feel should be brought to your attention. > > 1. Section 5.3 (Zip Relative Paths). The ABNF defines "language-range". I > think > this is not desirable. Language ranges are input to the matching algorithm > (i.e. > the user's request). You don't really want paths like "locale/de-*-1901". You > want concrete paths here and "*" has no business in a path. Ideally you would > reference the "Language-Tag" production in BCP 47 (RFC 5646). However, since > it is a large production and you don't probably want to directly incorporate > it, > you could incorporate the "obs-language-tag" production in the same document > instead. You should still say that language tags used in paths "must" be valid > language tags according to the more formal production. > > 2. Section 5.3. The same production corresponds to BCP 47 (RFC 4647) > "extended-language-range", although it only allows the tags to use lowercase > letters. I really feel that mixed case is not that difficult to support and > that it > will save many developers from inexplicable silent failures. > > 3. There is no mention of case sensitivity of filenames anywhere that I can > find. > You should define if filenames are case sensitive (or not) and what is meant > by > "case sensitive" if it is supported (just ASCII case? Unicode default case > mapping?) > > Thanks, > > Addison > > Addison Phillips > Globalization Architect (Lab126) > Chair (W3C I18N, IETF IRI WGs) > > Internationalization is not a feature. > It is an architecture.
Re: API for matrix manipulation
On Tue, Mar 15, 2011 at 5:00 PM, Chris Marrin wrote: > I think it would be nice to unify the classes somehow. But that might be > difficult since SVG and CSS are (necessarily) separate specs. But maybe one > of the API gurus has a solution? We just discussed this on Monday at the FXTF telcon. Sounds like people are, in general, okay with just using a 4x4 matrix, though there are some possible implementation issues with devices that can't do 3d at all. (It was suggested that they can simply do a 2d projection, which is simple.) ~TJ
Re: API for matrix manipulation
On Mar 15, 2011, at 2:49 PM, Gregg Tavares (wrk) wrote: > > > On Mon, Mar 14, 2011 at 4:27 PM, Chris Marrin wrote: > > On Mar 14, 2011, at 12:19 PM, Lars Knudsen wrote: > > > Hi, > > > > related to this: Is there any work ongoing to tie these (or more generic > > vector / matrix) classes to OpenCL / WebCL for faster computation across > > CPUs and GPUs? > > On WebKit I've experimented with an API to copy a CSSMatrix to an > Float32Array, which can be directly uploaded to the GPU. It's surprising how > much more efficient this was than copying the 16 floating point values out of > the CSSMatrix using JS. But I've hesitated proposing such an API while WebGL > and Typed Arrays were still in draft. Now that they're not, maybe it's time > to discuss it. > > I've also experimented with API in CSSMatrix to do in-place operations, > rather than creating a new CSSMatrix to hold the results. This too was a big > win, mostly I think because you get rid of all the churn of creating and > collecting CSSMatrix objects. > > > Would it be an even bigger win if CSSMatrix took a destination? That way you > can avoid all allocations where as if they do it in place then you always > need to make at least some copies to temps to get anything done. When you say "destination" are you talking about operating on a Typed Array buffer directly? I suppose that would be possible, but that would really just be like having 3D matrix operations on the Float32Array object. I think it would be a mistake to make yet another set of matrix functions! And one way or the other you need to copy data between types. You might be doing a CSS animation and you want to get the current matrix, put it in a Float32Array and send it to WebGL (I've done this, works great!). The cost of copying a matrix from a CSSMatrix to a Float32Array is so low relative to all the other call overhead that I don't think eliding that copy would buy much. But I might be wrong. - ~Chris cmar...@apple.com
Re: API for matrix manipulation
On Mar 14, 2011, at 6:54 PM, João Eiras wrote: > >>> Comments or is something already being worked on ? >> >> There are already 2 such classes: SVGMatrix and CSSMatrix. The former is an >> affine transformation matrix (commonly misnamed a "2x3 matrix") and the >> latter is a 3D homogeneous transformation matrix (commonly correctly named a >> "4x4 matrix"). >> > > Are those classes in their current implementations thread-safe ? Could a Web > Worker easily do matrix calculations with them ? I would guess a basic > physics engine in a worker would be a nice use case. They are as thread safe as any other JavaScript classes, which is not at all :-) As I understand it, the data would have to be serialized to be sent between Workers and the main thread. > > And what about making something that is generic enough for both SVG and CSS, > or even full blown algebra ? And then specify bindings of implicit > conversions from those DOM classes into a basic ES matrix (if you would like > to call it that) ? Proposing a Matrix class in JavaScript is much different than adding classes to the browser to support the DOM API, which is what SVGMatrix and CSSMatrix are. I think it would be nice to unify the classes somehow. But that might be difficult since SVG and CSS are (necessarily) separate specs. But maybe one of the API gurus has a solution? - ~Chris cmar...@apple.com
Re: drop directories/folders
WebKit or more specifically Chromium has the "webkitdirectory" attribute
that can be placed on a file input.
When you choose a directory it populates the FileList object with all the
files within the selected directory, however there is a bug[1] at the
moment. When you drag and drop a directory the FileList object is populated
with the directory name and not the files within it.
This hasn't been defined nor am unaware of any editor draft for this
functionality.
-Ryan
[1] http://code.google.com/p/chromium/issues/detail?id=58977
On Tue, Mar 15, 2011 at 8:59 PM, Rüdiger Kurz wrote:
> Hi,
>
> this is Rüdiger I’m a developer from Alkacon Software GmbH in Cologne,
> Germany. This year we are planning to release our new version 8 of OpenCms.
> Therefore we want to support our customers with a File API / FormData based
> upload functionality. This new upload feature should also provide drag and
> drop.
>
> ###
>
> Context: HTML5 - File API in combination with Drag and Drop
>
> Problem: If you drop directories/folders on to a defined "dropzone", I
> assume that it is not possible to "detect" that the dropped file is a
> directory.
>
> Target: When a user drops a directory, I want to inform the user in some
> way that directories can't be handled by the "program".
>
> Note: I know that it should not be possible to read a whole directory
> structure for security reason and that is not the point I want to make.
>
> Suggestion: Extend the File Interface for a attribute called directory
>
> interface File : Blob {
> readonly attribute DOMString name;
> readonly attribute DOMString directory;
> readonly attribute DOMString lastModifiedDate;
> };
>
> directory: Has the value 'true' if the file is a directory, 'false'
> otherwise
>
>
> Kind regards
>
> --
> Rüdiger Kurz
>
> ---
>
> Visit OpenCms Days 2011 Conference and Expo
> May 9 to May 10 2011 in Cologne, Germany
> http://www.opencms-days.org
>
> Alkacon Software GmbH - The OpenCms Experts
> Rüdiger Kurz
> An der Wachsfabrik 13
> 50996 Koeln, DE
>
> Tel: <%2B49%20%280%292236%203826-16>+49 (0)2236 3826-16
> Fax: <%2B49%20%280%292236%203826-20>+49 (0)2236 3826-20
> Email: r.k...@alkacon.com
>
> http://www.alkacon.com
> http://www.opencms.org
>
> Geschäftsführer: Alexander Kandzior, Amtsgericht Köln, HRB 54613
>
>
>
Re: Indexed Database API
Filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12310 On Fri, Mar 4, 2011 at 5:45 PM, Jeremy Orlow wrote: > On Fri, Mar 4, 2011 at 5:36 PM, Jonas Sicking wrote: > >> A few observations: >> >> 1. It seems like a fairly rare use case to have to jump to item #100 >> without first also observing item 1-99. When showing a paged view >> which lets the user to jump directly to, say, page 5 it can certainly >> happen, but the page could optimize for the case when the user first >> goes through page 1-4. >> 2. Since it's not a common case, adding support for it just on >> cursors, rather than cursors and objectStores, seems enough. Would be >> as simple as adding a .advance (or similarly named function) which >> simply takes an integer. I don't see that we need to support jumping >> in a arbitrary direction since we don't allow continue() in an >> arbitrary direction. >> 3. We do have a bit of a hole in our index-cursor API. While you can >> start the cursor at an arbitrary key, you can only start it at the >> first entry with that key in the case when there are duplicate keys. >> So if you iterate an index 10 records at a time, even if you never >> need to skip any entries, you can't always resume where you left off, >> even if you know the exact key+primaryKey for the record you want to >> resume at. >> > > I agree with all of this reasoning. > > >> 4. While I agree that count() seems like a useful function, my concern >> is that people might think it's a cheap operation. > > > This is my concern with your "getAll" function, btw. :-) > > >> Getting the count >> for a full objectStore or index should be quick, but getting the count >> for a given key range (such as on a cursor) seems like it could be >> expensive. My b-tree knowledge isn't the best, but isn't there a risk >> that you have to linearly walk the full keyrange? Or does b-trees keep >> an exact count of record in each node? Even if linear walking is >> required, there might not be much we can do, and the best we can do is >> to document that this is a slow operation. >> > > I don't think we should limit our thinking to btrees, but it seems as > though implementations could keep track of the number of children under a > particular node, in which case it should be faster than linear. > > COUNT(*) is a very popular function in SQL (even with WHERE clauses). It > seems like there will be some cases where the implementor truly does need a > count but not the data. And given that at least some implementations should > be able to optimize this, I think we should give them an API call. > > J > > On Fri, Mar 4, 2011 at 2:32 PM, Jeremy Orlow wrote: >> > On Fri, Mar 4, 2011 at 1:38 PM, ben turner >> wrote: >> >> >> >> Firefox does lazily deserialize cursor values, so the slowdown you're >> >> noticing is most likely due to us preserving the order of request >> >> callbacks by queuing every continue() call in line with the rest of >> >> the transaction. Jonas had proposed a faster, high performance cursor >> >> that did not respect this ordering, maybe that's all that you'd need. >> >> >> >> However, a few thoughts: >> >> >> >> 1. How do you know Page 5 even exists? We haven't exposed a count() >> >> function yet... >> >> 2. I think we should expose a count() function! >> >> 3. Maybe we should expose a getAt(long index, direction); >> >> function on indexes and objectStores? >> > >> > A count function might make sense. >> > But in this case, you could just jump forward to page 5 and see if you >> get >> > an error or not. >> > I'd lean towards just adding jumping forward to cursors for now though. >> If >> > getting a single item at some position is popular, then we can always >> add >> > it. >> > Let's avoid adding prioritization of cursor.continue calls unless we >> have >> > absolutely no other choice. >> > J >> >> >> >> On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay >> >> wrote: >> >> > On 03/02/2011 09:02 AM, Ben Dilts wrote: >> >> >> >> >> >> Why is there no mechanism for paging results, a la SQL's "limit"? >> If I >> >> >> want entries in positions 140-159 from an index, I have to call >> >> >> continue() on a cursor 139 times, which in turn unserializes 139 >> >> >> objects >> >> >> from my store that I don't care about, which in FF4 is making a >> lookup >> >> >> in IndexedDB sometimes take many seconds for even a few records. >> >> > >> >> > Sounds like there is something to optimize in the implementation. >> >> > Have you filed a bug >> >> > https://bugzilla.mozilla.org/enter_bug.cgi?product=Core >> >> > component DOM ? >> >> > If not, please do so and attach a *minimal* testcase. >> >> > >> >> > >> >> > Thanks, >> >> > >> >> > >> >> > -Olli >> >> > >> >> > >> >> > It >> >> >> >> >> >> makes no sense--am I just missing something in the spec? >> >> >> >> >> >> >> >> >> Ben Dilts >> >> > >> >> > >> >> >> > >> > >> > >
[Bug 12310] New: We should add IDBCursor.advance(number of items to move forward)
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12310 Summary: We should add IDBCursor.advance(number of items to move forward) Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We should add IDBCursor.advance(number of items to move forward). This was discussed in the thread "Indexed Database API" started by Ben Dilts. tl;dr of thread: the basic use case has to do with pagination across non-unique indexes and wanting to avoid making a large number of .continue() calls. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: API for matrix manipulation
On Mon, Mar 14, 2011 at 4:27 PM, Chris Marrin wrote: > > On Mar 14, 2011, at 12:19 PM, Lars Knudsen wrote: > > > Hi, > > > > related to this: Is there any work ongoing to tie these (or more generic > vector / matrix) classes to OpenCL / WebCL for faster computation across > CPUs and GPUs? > > On WebKit I've experimented with an API to copy a CSSMatrix to an > Float32Array, which can be directly uploaded to the GPU. It's surprising how > much more efficient this was than copying the 16 floating point values out > of the CSSMatrix using JS. But I've hesitated proposing such an API while > WebGL and Typed Arrays were still in draft. Now that they're not, maybe it's > time to discuss it. > > I've also experimented with API in CSSMatrix to do in-place operations, > rather than creating a new CSSMatrix to hold the results. This too was a big > win, mostly I think because you get rid of all the churn of creating and > collecting CSSMatrix objects. > > Would it be an even bigger win if CSSMatrix took a destination? That way you can avoid all allocations where as if they do it in place then you always need to make at least some copies to temps to get anything done. > - > ~Chris > cmar...@apple.com > > > > > >
Minor comments on Widgets
Hello Webapps WG, (these are personal comments) I happened to be referring to the Widget spec this morning and noticed a few minor items that I feel should be brought to your attention. 1. Section 5.3 (Zip Relative Paths). The ABNF defines "language-range". I think this is not desirable. Language ranges are input to the matching algorithm (i.e. the user's request). You don't really want paths like "locale/de-*-1901". You want concrete paths here and "*" has no business in a path. Ideally you would reference the "Language-Tag" production in BCP 47 (RFC 5646). However, since it is a large production and you don't probably want to directly incorporate it, you could incorporate the "obs-language-tag" production in the same document instead. You should still say that language tags used in paths "must" be valid language tags according to the more formal production. 2. Section 5.3. The same production corresponds to BCP 47 (RFC 4647) "extended-language-range", although it only allows the tags to use lowercase letters. I really feel that mixed case is not that difficult to support and that it will save many developers from inexplicable silent failures. 3. There is no mention of case sensitivity of filenames anywhere that I can find. You should define if filenames are case sensitive (or not) and what is meant by "case sensitive" if it is supported (just ASCII case? Unicode default case mapping?) Thanks, Addison Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs) Internationalization is not a feature. It is an architecture.
drop directories/folders
Hi,
this is Rüdiger I’m a developer from Alkacon Software GmbH in Cologne,
Germany. This year we are planning to release our new version 8 of
OpenCms. Therefore we want to support our customers with a File API /
FormData based upload functionality. This new upload feature should also
provide drag and drop.
###
Context: HTML5 - File API in combination with Drag and Drop
Problem: If you drop directories/folders on to a defined "dropzone", I
assume that it is not possible to "detect" that the dropped file is a
directory.
Target: When a user drops a directory, I want to inform the user in some
way that directories can't be handled by the "program".
Note: I know that it should not be possible to read a whole directory
structure for security reason and that is not the point I want to make.
Suggestion: Extend the File Interface for a attribute called directory
interface File : Blob {
readonly attribute DOMString name;
readonly attribute DOMString directory;
readonly attribute DOMString lastModifiedDate;
};
directory: Has the value 'true' if the file is a directory, 'false'
otherwise
Kind regards
--
Rüdiger Kurz
---
Visit OpenCms Days 2011 Conference and Expo
May 9 to May 10 2011 in Cologne, Germany
http://www.opencms-days.org
Alkacon Software GmbH - The OpenCms Experts
Rüdiger Kurz
An der Wachsfabrik 13
50996 Koeln, DE
Tel: +49 (0)2236 3826-16
Fax: +49 (0)2236 3826-20
Email: r.k...@alkacon.com
http://www.alkacon.com
http://www.opencms.org
Geschäftsführer: Alexander Kandzior, Amtsgericht Köln, HRB 54613
Re: API for matrix manipulation
Hi,
related to this: Is there any work ongoing to tie these (or more generic
vector / matrix) classes to OpenCL / WebCL for faster computation across
CPUs and GPUs?
- Lars
On Mon, Mar 14, 2011 at 5:17 PM, Chris Marrin wrote:
>
> On Mar 14, 2011, at 7:56 AM, João Eiras wrote:
>
> Hi.
>
> Given that a number of API are being developed that require complex
> matricial calculations (transforms, device orientation, web gl), I
> would suggest that perhaps an API with a big number of common
> calculations could be made available ? And a proper way to represent
> them. Perhaps, the best way to add this would be to extend the Math
> object with things like.
>
> Math.mAdd(m1, m2)
> Math.mSub(m1, m2)
> Math.mMult(m1, m2)
> Math.mDiv(m1, m2)
> Math.mInverse(m1)
> Math.mGaussianReduce(m1)
> Math.mRank(m1)
> Math.mRank(m1)
>
> Being the matrix an array like object like (could even be one of those
> fast arrays like ArrayBuffer).
>
> # {
> # w: ,
> # h: ,
> # length:
> # 0: ...,
> # 1: ...,
> # 2: ...
> # (...)
> # }
>
> Comments or is something already being worked on ?
>
>
> There are already 2 such classes: SVGMatrix and CSSMatrix. The former is an
> affine transformation matrix (commonly misnamed a "2x3 matrix") and the
> latter is a 3D homogeneous transformation matrix (commonly correctly named a
> "4x4 matrix").
>
> We added CSSMatrix to the CSS Transform Spec to give us the same
> functionality as SVG Matrix, but for 3D transforms. Therefore both of these
> classes are pretty light on their operators. It might be useful to discuss
> "one matrix to rule them all", which could be used in place of the current
> classes and with more functionality. But it's important not to go too far
> down this path, or you'll end up defining classes for Points, Lines, Planes,
> Bounding Boxes and View Volumes with dozens of functions. Down that path
> lies madness.
>
> I think the current spec handles the more complex (inverse and multiply)
> and more commonly used (scale, rotate, translate) functions. I'm not sure
> what adding and subtracting 2 matrices means, and division is handled by
> inverse and multiply. The others seem pretty domain specific for a general
> class. And remember you can (and many people have) created JS libraries to
> add funcrtions to the built-in matrix classes. I wrote one:
>
>
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/webkit/resources/J3DIMath.js
>
> which uses CSSMatrix if it exists and uses JS otherwise. It exposed some
> interesting deficiencies in the current CSSMatrix class. There are several
> bugs on WebKit to address these and other issues of matrix efficiency and
> functionality: 23799 ,
> 28850 ,
> 50633
> , 52488 . Perhaps it would
> be useful to open these (or similar) bugs on the w3c bug system?
>
> That's where I believe we are on the Matrix front.
>
> -
> ~Chris
> cmar...@apple.com
>
>
>
>
>
Re: [XHR2] timeout
On 11/12/2009 05:24 PM, Anne van Kesteren wrote:
On Wed, 11 Nov 2009 00:03:07 +0100, Jonas Sicking wrote:
On Tue, Nov 10, 2009 at 10:17 AM, Anne van Kesteren
wrote:
Anyway, do you have opinions on the synchronous case? Do you agree we
should use TIMEOUT_ERR there? What do the people from Microsoft think?
That makes sense to me.
I've now defined the timeout feature:
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
Please review it! (Same for FormData and really all other parts of the
specification.)
I think timeout is a bit too limiting. Especially the step
2. "If the send() flag is true raise an INVALID_STATE_ERR exception and
terminate these steps. "
What if dns resolving (or something else) takes just a bit too long and
then the timeout fires while something is being downloaded.
Whoever is using the API may have already read part of the data and may
want to get rest of it.
So, could we allow increasing timeout value also after send().
Setting timeout to 0 to clear it should also be possible.
This way one could increase the timeout if needed.
var xhr = new XMLHttpRequest();
xhr.open(...);
xhr.timeout = 1; //10s
xhr.onprogress = function(evt) {
// Ok, some progress is happening, increase the timeout so
// that only very slowly loading XHR is cancelled.
if (xhr.timeout == 1) {
xhr.timeout *= 2;
}
}
xhr.send();
-Olli
