Re: Polished FileSystem API proposal

[Jonas Sicking]

Or simply if we make it possible to pass a Directory through
postMessage then you can open another website in a sandboxed 
and pass it a Directory and let it modify its contents, without having
to grant access to other parts of the sandboxed filesystem.

/ Jonas

On Thu, Jul 18, 2013 at 5:02 PM, Anne van Kesteren  wrote:
> On Thu, Jul 18, 2013 at 4:52 PM, Mounir Lamouri  wrote:
>> Isn't a Directory object just a path? I mean, would you send the list of
>> files and their content or just the path to the directory? If you
>> literally want to pass the Directory object, I am not sure how passing
>> the path is different except that you would have to know if this is
>> temporary or permanent storage.
>
> If you use a sandboxed system like Caja you could imagine passing the
> Directory and thereby not exposing any of the files higher in the
> hierarchy. However, Caja could probably also work around this somehow
> given different primitives.
>
>
> --
> http://annevankesteren.nl/
>

Re: Polished FileSystem API proposal

[Anne van Kesteren]

On Thu, Jul 18, 2013 at 4:52 PM, Mounir Lamouri  wrote:
> Isn't a Directory object just a path? I mean, would you send the list of
> files and their content or just the path to the directory? If you
> literally want to pass the Directory object, I am not sure how passing
> the path is different except that you would have to know if this is
> temporary or permanent storage.

If you use a sandboxed system like Caja you could imagine passing the
Directory and thereby not exposing any of the files higher in the
hierarchy. However, Caja could probably also work around this somehow
given different primitives.


--
http://annevankesteren.nl/

Re: Polished FileSystem API proposal

[Mounir Lamouri]

On 15/07/13 23:26, Kinuko Yasuda wrote:
> OTOH one limitation I could think of in not having JS object is it'll
> disallow a possible future API expansion for sending a 'Directory'
> object to another app by postMessage.  (It's another popular request we
> get in Chrome)

Isn't a Directory object just a path? I mean, would you send the list of
files and their content or just the path to the directory? If you
literally want to pass the Directory object, I am not sure how passing
the path is different except that you would have to know if this is
temporary or permanent storage.

--
Mounir

Re: URLs into IndexedDB databases

[Jonas Sicking]

On Thu, Jul 18, 2013 at 6:58 AM, Kornel Lesiński  wrote:
> On Mon, 15 Jul 2013 09:57:30 +0100, Jonas Sicking  wrote:
>
>>
>> indexeddb://
>>
>> Each piece above would have to be encoded such that it contains only
>> valid, non-'/', URL characters. For things like database name and
>> objectStore name this is easy by simply %-encoding characters.
>>
>> For the key this is significantly messier. We have to encode things
>> like Dates and numbers, as well as Arrays. There's no shortage of ways
>> of doing this, but there's no particularly clean way to do it either I
>> think.
>
>
> That makes sense and I think key encoding is solvable with some microsyntax
> (I'll refrain from bikeshedding it here :)
>
>
> But what these URLs will be used for? Probably not for simple values that
> are smaller than the URL itself (what can you do with a URL that points to
> an integer?)
>
> So maybe the key use-case will be linking to Blobs in indexedb (e.g. images,
> full documents) and then it would suffice if only those Blobs had permanent
> URLs (e.g. window.URL.createObjectURL would be permanent for stored blobs).

I think loading blobs is the main use case yes. But I don't think
changing createObjectURL to sometimes return URLs with permanent
semantics, and sometimes return URLs with temporary semantics is a
good idea.

Also, keep in mind that the use case here is being URLs that are
*predictable* URLs, not just permanent. Even if we generated permanent
blob: URLs for Blobs stored in indexedDB, you would need to
store that URL somewhere and then retrieve it when you want to use it.
Having to do that database operation sort of defeats the purpose of
what I was trying to do here.

/ Jonas

Re: [webappsec + webapps] CORS to PR plans

[Arthur Barstow]

On 7/16/13 3:47 PM, ext Brad Hill wrote:
CORS advanced to Candidate Recommendation this January, and I believe 
it is time we consider advancing it to Proposed Recommendation.  In 
the absence of an editor, I have been collecting bug reports sent to 
the public-webappsec list, and now have a proposed draft incorporating 
these fixes I would like to run by both WGs.


The proposed draft can be found at:

http://webappsec-test.info/~bhill2/pub/CORS/index.html 



A diff-marked version is available at:

http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FCR-cors-20130129%2F&doc2=http%3A%2F%2Fwebappsec-test.info%2F~bhill2%2Fpub%2FCORS%2Findex.html 



Thanks very much for doing this work Brad!


If these changes are acceptable to the WGs,


The changes seem reasonable to me.

I believe the only remaining steps are to prepare an implementation 
report and update the test suite to cover the 204 and 308 status 
codes.   I'll let us discuss these for a bit here before beginning a 
formal call for consensus.


Sounds GTM.

-ArtB

HTML as application manifest format

[Kornel Lesiński]

I'd like to propose using HTML as basis of manifest format, similar in  
spirit to Web Components imports, e.g.




and then my-app-definition.html could contain ,  or other  
elements.



Rationale:

* while JSON is wonderful for automatic serialization, it's an annoying  
format when maintained by hand (and manifest seems static and simple  
enough to be maintained by hand).


  - JSON syntax is pedantic about trailing comma. Authors have to be  
careful when adding new element to end of a list.


  - JSON does not support comments. Manifest is a central place of an  
application, so may end up being modified by many team members, and it's  
useful to comment why certain properties are the way they are, warn which  
changes will cause breakage (again…), etc.


* We already have , , name="application-name"> that can be reused. Authors already know these  
and it may be easier to define and understand how  and manifest  
properties interact.


* We already have lang & hreflang attributes, so there's no need to invent  
locales dictionaries.


* It can be inlined naturally, saving a RTT.

* It can be mixed with Web Components allowing applications to define  
everything in one place if they wish to.


* Simple websites can reuse homepage as their manifest file: rel=manifest href=/>




Here's HTMLized example from the spec:
http://www.w3.org/2012/sysapps/manifest/#example-manifest












http://example.org/dev";>
https://example.org/dev/es-ES";>

@viewport {
  min-width: 300px;
  max-width: 600px;
}











When writing this I was surprised how well existing functionality fits  
(and thus how much "NIH" can be avoided).


The only bit that didn't seem natural fit was  for permissions, so  
maybe a better element needs to be invented for it:



 
 


or perhaps made generic:


  
 
 
 
  


--
regards, Kornel

Re: URLs into IndexedDB databases

[Kornel Lesiński]

On Mon, 15 Jul 2013 09:57:30 +0100, Jonas Sicking  wrote:


indexeddb://

Each piece above would have to be encoded such that it contains only
valid, non-'/', URL characters. For things like database name and
objectStore name this is easy by simply %-encoding characters.

For the key this is significantly messier. We have to encode things
like Dates and numbers, as well as Arrays. There's no shortage of ways
of doing this, but there's no particularly clean way to do it either I
think.


That makes sense and I think key encoding is solvable with some  
microsyntax (I'll refrain from bikeshedding it here :)



But what these URLs will be used for? Probably not for simple values that  
are smaller than the URL itself (what can you do with a URL that points to  
an integer?)


So maybe the key use-case will be linking to Blobs in indexedb (e.g.  
images, full documents) and then it would suffice if only those Blobs had  
permanent URLs (e.g. window.URL.createObjectURL would be permanent for  
stored blobs).



A third problem here is that it seems unfortunate to generate a new
URL scheme for each storage format we have.


I don't see a problem with that. If they have different addressing scheme,  
they logically should have different URL scheme. localdata: just pushes  
scheme name to the path.


--
regards, Kornel