Re: New draft of FileSystem API posted
Hi Eric,
Thanks for your reply.
Actually after sending that email I had started to think that caching isFile
/ isDirectory information in memory would be ok if user could get an
informative error code when an entry becomes stale -- and seems like that's
the case. So I'm almost convinced :)
One thing I'm not fully convinced yet about FileEntry / DirectoryEntry is
if we really want to make FileEntry a subclass of File.
To me it looks like they have slightly different semantics - File is an
immutable snapshot of file content, while Entry is more like a handle for
meta-level operations that actually modify the underlying disk image.
File's size attribute and slice() method assume its snapshot doesn't change
after it was captured, but FileEntry has createWriter method and it will
likely change the file content. It brings several questions: if FileEntry
== File in what timing are UAs supposed to capture a snapshot? Do we want
to have a synchronous size attribute on a mutable Entry? If we move an
Entry to another name, does its File.type need to change according to its
new name?
On Wed, Aug 11, 2010 at 1:25 PM, Eric Uhrhane er...@google.com wrote:
My apologies for the slow response; I'm now back from my vacation.
On Tue, Jul 20, 2010 at 6:27 PM, Kinuko Yasuda kin...@google.com wrote:
Hi Eric,
Thanks for brushing up the draft.
We had some internal discussion about the API details and came up with a
question regarding is{File,Directory} attributes of Entry interface.
It seems like user agent needs to be able to tell if a given entry is
file
or directory synchronously (or from its cache), but we wonder what should
happen if the underlying file object is changed later. For example, we
may
have a situation like this:
1. a user code gets (or creates) a file entry.
2. another flow of the code (or another code in the same origin) removes
the
same entry and creates a *directory* at the same path.
3. the original code refers isFile attribute of the entry. -- should it
be
true or false?
My intention was that the UA would look up that information when first
creating the Entry and keep it cached. It's not the kind of thing
that changes very often, so I didn't think we needed it to be a live
query every time. If the user tries to write to a file that's become
a directory, or vice-versa, that's what INVALID_STATE_ERROR is for.
This is an unusual error, thus it's appropriate that it be handled via
exception.
If an Entry is just a reference (i.e. a pathname) of a system file entity,
it would look natural that it is resolved at run-time thus returns false
in
the above case. But if so we'll have two problems: 1) we'll need to
make
synchronous stat calls to get the attribute values, and 2) as we have
different interfaces for file and directory, we may end up with having
invalid FileEntry objects for directories - or vice versa.
Would it be possible to have a single unified interface for file and
directory and let scripts figure out the info at runtime (e.g. in each
asynchronous filesystem operation)?
Do you mean, allow all file operations and directory operation, and
fail if you use the wrong one? UAs already have to fail on operations
that don't make sense [or fail in the underlying implementation],
whether or not we keep a unified interface, so I think that would just
clutter up each subtype with the others' methods.
If I'm misunderstanding you, please give an example of your proposed
interface and a situation which it would improve.
You're not misunderstanding me. I meant if UAs didn't cache the
information that an entry is file or directory it would be natural to make
wrong operations fail at run-time, but otherwise I fully agree that
cluttering up subtypes with irrelevant methods is not a good idea.
On Wed, Jul 7, 2010 at 6:50 PM, Eric Uhrhane er...@google.com wrote:
I've posted a new draft of File API: Directories and System [1]. In
this draft I've rolled in quite a bit of feedback that I received
since first posting it on DAP--many apologies for the delay. This is
the first draft produced since we agreed to move this spec from DAP to
WebApps; I hope those of you who have time will give it a look and let
me know what you think.
In general I've tried to address any comment I was sent and had not
already addressed via email. The few that didn't make it in, I've
responded to below.
My thanks to Robin Berjon and Mike Clement for all their feedback.
Robin:
- data stored there by the application should not be deleted by the
UA without user intervention, UA should require permission from the
user, The application may of course delete it at will - these
sound like real conformance statements, therefore SHOULD, SHOULD NOT,
and MAY.
Those are in a non-normative section; is that language still appropriate
there?
Robin:
[discussion about speccing the URI format]
Left as an open issue.
[Bug 9745] We should require nextprotoneg support when doing the TLS handshake for WebSocket.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9745 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2010-08-13 07:25:35 --- Done. -- 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: [IndexedDB] Languages for collation
On Fri, Aug 13, 2010 at 1:31 AM, Pablo Castro pablo.cas...@microsoft.comwrote: From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow Sent: Thursday, August 12, 2010 2:18 AM I think we should first break down the use cases and look at how many of them just need _a_ sort order, how many of them a per-database sort order is ok, and how many of them would need something finer grained (like a per-key ordering). That's reasonable. What I was thinking is that any case where you'll use the order of items in a store/index to display things to the user (e.g. a list of contacts) you'd want the items to be in proper order for the user's language. That will not only match users' expectations but also match other applications (or even other parts of the UA) that display data based on the current OS language or the users' choice of language. That covers a very broad spectrum of scenarios that need language-specific sort order. I find it unlikely that a single web app will need more than one language per database (or even per origin/OS account), given that most applications operate in a single language at any one point in time. A lot of people are multi-lingual and I'm sure there will be at least some apps that need different data sorted in different ways for each language used. It's quite likely that such apps could use multiple databases as a work-around though. (As long as they don't need to execute transactions between them.) Are there work-arounds for getting an UCA ordered data structure to hold data other language's order? For example, I could imagine it'd be possible to do some sort of encode step on the data before insertion (and decode on removal) that would make UCA work. I have no idea, but if such algorithms existed and were well understood, then it'd definitely make me lean towards punting language specification to v2. I'm not sure I understand this paragraph. UCA ordered may not mean much more than just ordering using a binary collation if the language is not specified. While this is typically not an issue in English, in other languages this introduces a varying level of deviation from users' expectations. Given that different languages have conflicting rules for collation, I'm not sure how this can be generalized independently of the language. Even in the UCA specification [1] the aspect of input language is mentioned as the most important feature of collation. I understand that. What I was asking is whether there are hacks to make it work anyway. i.e. ways to encode/decode the data going in/out. In other words, what's stored as the key would not be exactly the word you put in, but you'd know how to undo the process on the way out. After thinking about it for a couple minutes, I've got some ideas on how to do it, but they're not terribly lightweight. Btw, my intuition is also that a database level control is the right way to go here, but I just want to make sure we've properly considered the pros and cons of the other possibilities. J
Re: [XHR] Redirects
On Fri, 2010-08-13 at 00:03 +0200, Anne van Kesteren wrote: On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras joao.ei...@gmail.com wrote: b) Could there be a way to opt-in into not following redirection chains ? For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj. What is the use case? We might add something like this at some point (probably by way of a followRedirects boolean) but so far the use cases have not been really strong so it has not been given much priority. A boolean flag would be fine for my use case, which is a 303 following a POST. The POST request is sent over XHR, but the target location of the redirect is an HTML document that should be shown to the user in the browser window. I need to have access to the target location in JavaScript to direct the browser window to that location. James
Re: [XHR] Redirects
On 13.08.2010 00:03, Anne van Kesteren wrote: ... For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj. What is the use case? ... Some that come to mind quickly: - Depending on the redirect status, you may want to stop accessing the original URI. - Depending on the method, you may want to confirm with the user whether automatically following the redirect is ok. - You may want to display the actual URI somewhere in the UI. Best regards, Julian
Re: [XHR] Redirects
Julian Reschke wrote: On 13.08.2010 00:03, Anne van Kesteren wrote: ... For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj. What is the use case? ... Some that come to mind quickly: - Depending on the redirect status, you may want to stop accessing the original URI. - Depending on the method, you may want to confirm with the user whether automatically following the redirect is ok. - You may want to display the actual URI somewhere in the UI. and - You may need to use the URI to perform PUT/DELETE operations - You may need the URI to resolve relative references within response headers or the message-body
[widgets] CfC to remove openURL from Widget object; deadline August 25
This is a Call for Consensus to remove the openURL method from the Widget object as captured in Issue-116 and Action-568 and discussed on the mail list ([1], [2], [3]) and during several calls (most recently [4], [5]): * Issue-116 Need to flesh out the security considerations for the openURL method in the Widget Interface spec http://www.w3.org/2008/webapps/track/issues/116 * Action-568 http://www.w3.org/2008/webapps/track/actions/568 If this proposal is agreed, the Widget Interface spec will be republished as a new Last Call Working Draft. (It may be possible to skip publishing a new Candidate and proceed directly to Proposed Recommendation [6] but that process issue can be discussed separately). The deadline for responses is August 25. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0570.html [2] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0125.html [3] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0394.html [4] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0475.html [5] http://www.w3.org/2010/07/08-wam-minutes.html#item04 [6] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
Re: [IndexedDB] Languages for collation
On Fri, Aug 13, 2010 at 4:56 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Aug 13, 2010 at 1:31 AM, Pablo Castro pablo.cas...@microsoft.com
wrote:
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy
Orlow
Sent: Thursday, August 12, 2010 2:18 AM
I think we should first break down the use cases and look at how many
of them just need _a_ sort order, how many of them a per-database sort
order
is ok, and how many of them would need something finer grained (like a
per-key ordering).
That's reasonable. What I was thinking is that any case where you'll use
the order of items in a store/index to display things to the user (e.g. a
list of contacts) you'd want the items to be in proper order for the user's
language. That will not only match users' expectations but also match other
applications (or even other parts of the UA) that display data based on the
current OS language or the users' choice of language.
That covers a very broad spectrum of scenarios that need language-specific
sort order.
I find it unlikely that a single web app will need more than one language
per database (or even per origin/OS account), given that most applications
operate in a single language at any one point in time.
A lot of people are multi-lingual and I'm sure there will be at least some
apps that need different data sorted in different ways for each language
used. It's quite likely that such apps could use multiple databases as a
work-around though. (As long as they don't need to execute transactions
between them.)
I can give some input as a multi-lingual person here. The only time
I've used multiple languages at the same time in an application is for
spell checking. In my browser I sometimes end up with setting the
language in one textbox to swedish, and another to english. It's often
annoying how poorly this use case is supported in applications
actually.
However I've never been in a situation where I've wanted some lists
sorted in swedish and some in english. Possibly you would want to have
spelling suggestions for a swedish textbox sorted in swedish order,
and spelling suggestions for an english textbox sorted in english
order. Though I think it wouldn't be much problem to have the
different dictionaries in different databases.
From an API point of view I think it would be pretty easy to support
setting collation for individual objectStores. All we'd need is
something like:
interface IDBObjectStore {
...
IDBRequest setSortingLanguage(in DOMString languageCode);
IDBRequest getSortingLanguage();
...
};
To call setSortingLanguage you'd need READ_WRITE access. It acts just
like any other writing request, with the only difference that it can
take a lng time to execute. We could even add these functions to
IDBIndex to allow the same data to be sorted in different ways at the
same time.
However I think it's very rare that this will be needed. And there are
ways to somewhat work around it by using separate databases. So I
would probably say that lets keep it database-wide for now, and
reconsider in version 2.
/ Jonas
Re: [IndexedDB] Languages for collation
On Fri, Aug 13, 2010 at 5:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 13, 2010 at 4:56 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Aug 13, 2010 at 1:31 AM, Pablo Castro
pablo.cas...@microsoft.com
wrote:
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy
Orlow
Sent: Thursday, August 12, 2010 2:18 AM
I think we should first break down the use cases and look at how many
of them just need _a_ sort order, how many of them a per-database
sort order
is ok, and how many of them would need something finer grained (like
a
per-key ordering).
That's reasonable. What I was thinking is that any case where you'll use
the order of items in a store/index to display things to the user (e.g.
a
list of contacts) you'd want the items to be in proper order for the
user's
language. That will not only match users' expectations but also match
other
applications (or even other parts of the UA) that display data based on
the
current OS language or the users' choice of language.
That covers a very broad spectrum of scenarios that need
language-specific
sort order.
I find it unlikely that a single web app will need more than one
language
per database (or even per origin/OS account), given that most
applications
operate in a single language at any one point in time.
A lot of people are multi-lingual and I'm sure there will be at least
some
apps that need different data sorted in different ways for each language
used. It's quite likely that such apps could use multiple databases as a
work-around though. (As long as they don't need to execute transactions
between them.)
I can give some input as a multi-lingual person here. The only time
I've used multiple languages at the same time in an application is for
spell checking. In my browser I sometimes end up with setting the
language in one textbox to swedish, and another to english. It's often
annoying how poorly this use case is supported in applications
actually.
However I've never been in a situation where I've wanted some lists
sorted in swedish and some in english. Possibly you would want to have
spelling suggestions for a swedish textbox sorted in swedish order,
and spelling suggestions for an english textbox sorted in english
order. Though I think it wouldn't be much problem to have the
different dictionaries in different databases.
From an API point of view I think it would be pretty easy to support
setting collation for individual objectStores. All we'd need is
something like:
interface IDBObjectStore {
...
IDBRequest setSortingLanguage(in DOMString languageCode);
IDBRequest getSortingLanguage();
...
};
To call setSortingLanguage you'd need READ_WRITE access. It acts just
like any other writing request, with the only difference that it can
take a lng time to execute. We could even add these functions to
IDBIndex to allow the same data to be sorted in different ways at the
same time.
Why not put it behind setVersion and just make it an optional parameter when
creating objectStores and indexes? I agree with Pablo that these things
really shouldn't be changing much--in fact, maybe it's not worth making
them modifiable at all (without rebuilding a new objectStore/index
yourself).
However I think it's very rare that this will be needed. And there are
ways to somewhat work around it by using separate databases. So I
would probably say that lets keep it database-wide for now, and
reconsider in version 2.
On the other hand, is there any reason not to make it per-objectStore/index?
As far as I can tell, it should actually be fairly light weight form an API
point of view: we can just add it as an optional parameter to
createObjectStore/createIndex. From an implementation point of view, I
really don't see this being much overhead either. So maybe we should just
do it?
The alternative is to add a function within setVersion to set the language
which actually seems less elegant.
J
Re: New draft of FileSystem API posted
On Fri, Aug 13, 2010 at 10:58 AM, Eric Uhrhane er...@google.com wrote:
On Thu, Aug 12, 2010 at 11:08 PM, Kinuko Yasuda kin...@chromium.org
wrote:
Hi Eric,
Thanks for your reply.
Actually after sending that email I had started to think that caching
isFile
/ isDirectory information in memory would be ok if user could get an
informative error code when an entry becomes stale -- and seems like
that's
the case. So I'm almost convinced :)
One thing I'm not fully convinced yet about FileEntry / DirectoryEntry is
if we really want to make FileEntry a subclass of File.
To me it looks like they have slightly different semantics - File is an
immutable snapshot of file content, while Entry is more like a handle for
meta-level operations that actually modify the underlying disk image.
File's size attribute and slice() method assume its snapshot doesn't
change
after it was captured, but FileEntry has createWriter method and it will
likely change the file content. It brings several questions: if
FileEntry
== File in what timing are UAs supposed to capture a snapshot? Do we
want
to have a synchronous size attribute on a mutable Entry? If we move an
Entry to another name, does its File.type need to change according to its
new name?
You're quite right. A mutable FileEntry shouldn't have a synchronous
size member, and slice() and type are likewise problematic.
How about if we add a getFile() method that returns a File object,
snapshotted at the time of the call? Hmm...that name's going to be a
bit confusing, though, since there's a getFile on DirectoryEntry that
does something completely different. Perhaps just file()? It should
definitely be a method, not a member, to make clear that it's making
calls to the underlying filesystem.
file() sounds good to me.
(Oh yes we have getFile on DirectoryEntry...)
On Wed, Aug 11, 2010 at 1:25 PM, Eric Uhrhane er...@google.com wrote:
My apologies for the slow response; I'm now back from my vacation.
On Tue, Jul 20, 2010 at 6:27 PM, Kinuko Yasuda kin...@google.com
wrote:
Hi Eric,
Thanks for brushing up the draft.
We had some internal discussion about the API details and came up with
a
question regarding is{File,Directory} attributes of Entry interface.
It seems like user agent needs to be able to tell if a given entry is
file
or directory synchronously (or from its cache), but we wonder what
should
happen if the underlying file object is changed later. For example,
we
may
have a situation like this:
1. a user code gets (or creates) a file entry.
2. another flow of the code (or another code in the same
origin) removes
the
same entry and creates a *directory* at the same path.
3. the original code refers isFile attribute of the entry. -- should
it
be
true or false?
My intention was that the UA would look up that information when first
creating the Entry and keep it cached. It's not the kind of thing
that changes very often, so I didn't think we needed it to be a live
query every time. If the user tries to write to a file that's become
a directory, or vice-versa, that's what INVALID_STATE_ERROR is for.
This is an unusual error, thus it's appropriate that it be handled via
exception.
If an Entry is just a reference (i.e. a pathname) of a system file
entity,
it would look natural that it is resolved at run-time thus returns
false
in
the above case. But if so we'll have two problems: 1) we'll need to
make
synchronous stat calls to get the attribute values, and 2) as we have
different interfaces for file and directory, we may end up with having
invalid FileEntry objects for directories - or vice versa.
Would it be possible to have a single unified interface for file and
directory and let scripts figure out the info at runtime (e.g. in each
asynchronous filesystem operation)?
Do you mean, allow all file operations and directory operation, and
fail if you use the wrong one? UAs already have to fail on operations
that don't make sense [or fail in the underlying implementation],
whether or not we keep a unified interface, so I think that would just
clutter up each subtype with the others' methods.
If I'm misunderstanding you, please give an example of your proposed
interface and a situation which it would improve.
You're not misunderstanding me. I meant if UAs didn't cache the
information that an entry is file or directory it would be natural to
make
wrong operations fail at run-time, but otherwise I fully agree that
cluttering up subtypes with irrelevant methods is not a good idea.
On Wed, Jul 7, 2010 at 6:50 PM, Eric Uhrhane er...@google.com
wrote:
I've posted a new draft of File API: Directories and System [1]. In
this draft I've rolled in quite a bit of feedback that I received
since first posting it on DAP--many apologies for the delay. This
[IndexedDB] Avoiding reader/writer starvation
In the context of transactions, readers using READ_ONLY and writers using READ_WRITE may block each other when starting transactions, at least for cases where the underlying implementation uses locking for isolation. Since we allow multiple readers and they can start while other readers were already running, it's possible that readers end up starving writers in a concurrent setting. It seems it would be a good idea to add some minimum guarantees to the spec that ensures some amount of fairness to concurrent activities against a given database. We could either include a loose recommendation or try to mandate a strict behavior. It seems the loose recommendation is more practical, the questions are a) is there a risk of incompatible behavior because of under-specification, and b) will we risk that some implementations will just ignore this aspect if it's specified too informally. The loose recommendation could just be a sentence in the transactions section: UAs need to ensure a reasonable level of fairness across readers and writers to prevent starvation. If we wanted to be more specific, we could go with something like this (we'd probably spell it out as rules if we decide to put this strict version in the spec): All readers can run concurrently, but once a writer tries to start a transaction we stop allowing new readers to start and queue up the writer and any subsequent reader/writer. Once the existing readers are drained the writer runs, and after that whatever is queued up next runs, which can be another writer or all the remaining readers (depending upon what came first, another writer or another reader; readers are released all simultaneously since they run concurrently). Given that not all implementations will have to deal with this and that different implementations may want to have different strategies, it seems that just having the recommendation around starvation is the best option. Thanks -pablo
Re: New draft of FileSystem API posted
Fixed.
While I was in there, I deleted an unused class [FileSystemsCallback]
and changed the boolean persistent parameter [from requestFileSystem
and requestFileSystemSync] to be a more-general flag, to allow for
future expansion.
Eric
On Fri, Aug 13, 2010 at 11:23 AM, Kinuko Yasuda kin...@chromium.org wrote:
On Fri, Aug 13, 2010 at 10:58 AM, Eric Uhrhane er...@google.com wrote:
On Thu, Aug 12, 2010 at 11:08 PM, Kinuko Yasuda kin...@chromium.org
wrote:
Hi Eric,
Thanks for your reply.
Actually after sending that email I had started to think that caching
isFile
/ isDirectory information in memory would be ok if user could get an
informative error code when an entry becomes stale -- and seems like
that's
the case. So I'm almost convinced :)
One thing I'm not fully convinced yet about FileEntry / DirectoryEntry
is
if we really want to make FileEntry a subclass of File.
To me it looks like they have slightly different semantics - File is an
immutable snapshot of file content, while Entry is more like a handle
for
meta-level operations that actually modify the underlying disk image.
File's size attribute and slice() method assume its snapshot doesn't
change
after it was captured, but FileEntry has createWriter method and it will
likely change the file content. It brings several questions: if
FileEntry
== File in what timing are UAs supposed to capture a snapshot? Do we
want
to have a synchronous size attribute on a mutable Entry? If we move an
Entry to another name, does its File.type need to change according to
its
new name?
You're quite right. A mutable FileEntry shouldn't have a synchronous
size member, and slice() and type are likewise problematic.
How about if we add a getFile() method that returns a File object,
snapshotted at the time of the call? Hmm...that name's going to be a
bit confusing, though, since there's a getFile on DirectoryEntry that
does something completely different. Perhaps just file()? It should
definitely be a method, not a member, to make clear that it's making
calls to the underlying filesystem.
file() sounds good to me.
(Oh yes we have getFile on DirectoryEntry...)
On Wed, Aug 11, 2010 at 1:25 PM, Eric Uhrhane er...@google.com wrote:
My apologies for the slow response; I'm now back from my vacation.
On Tue, Jul 20, 2010 at 6:27 PM, Kinuko Yasuda kin...@google.com
wrote:
Hi Eric,
Thanks for brushing up the draft.
We had some internal discussion about the API details and came up
with a
question regarding is{File,Directory} attributes of Entry interface.
It seems like user agent needs to be able to tell if a given entry is
file
or directory synchronously (or from its cache), but we wonder what
should
happen if the underlying file object is changed later. For example,
we
may
have a situation like this:
1. a user code gets (or creates) a file entry.
2. another flow of the code (or another code in the same
origin) removes
the
same entry and creates a *directory* at the same path.
3. the original code refers isFile attribute of the entry. -- should
it
be
true or false?
My intention was that the UA would look up that information when first
creating the Entry and keep it cached. It's not the kind of thing
that changes very often, so I didn't think we needed it to be a live
query every time. If the user tries to write to a file that's become
a directory, or vice-versa, that's what INVALID_STATE_ERROR is for.
This is an unusual error, thus it's appropriate that it be handled via
exception.
If an Entry is just a reference (i.e. a pathname) of a system file
entity,
it would look natural that it is resolved at run-time thus returns
false
in
the above case. But if so we'll have two problems: 1) we'll need to
make
synchronous stat calls to get the attribute values, and 2) as we have
different interfaces for file and directory, we may end up with
having
invalid FileEntry objects for directories - or vice versa.
Would it be possible to have a single unified interface for file and
directory and let scripts figure out the info at runtime (e.g. in
each
asynchronous filesystem operation)?
Do you mean, allow all file operations and directory operation, and
fail if you use the wrong one? UAs already have to fail on operations
that don't make sense [or fail in the underlying implementation],
whether or not we keep a unified interface, so I think that would just
clutter up each subtype with the others' methods.
If I'm misunderstanding you, please give an example of your proposed
interface and a situation which it would improve.
You're not misunderstanding me. I meant if UAs didn't cache the
information that an entry is file or directory it would be natural to
make
wrong operations fail at run-time, but otherwise I fully agree that
cluttering
Re: [widgets] Widgets Updates
Comments: Should we have a more explicit way to specify and notify users that some updates may require data conversion and user data will be converted after the widget is updated? Due to the error-prone nature of such conversion, users may want to back up their data before proceeding with an update. B. On 8/11/10 2:34 AM, Rich Tibbett wrote: Over the last few days I've been updating the Widgets Updates specification with Marcos. The latest editor's draft is available here: http://dev.w3.org/2006/waf/widgets-updates/ Please review and propose any input or feedback on the mailing list. This draft does not assume consensus of the working group on the material at this point. Kind regards, Rich -- Rich Tibbett Opera Software
