implement flash.filesystem classes

[GoogleCodeExporter]

based on the POSIX API, FileSystem API etc.

we need to implement flash.filesystem
  * File
  * FileMode
  * FileStream

etc.

StorageVolume is not a priority

Original issue reported on code.google.com by zwetan on 20 Aug 2014 at 9:31

[GoogleCodeExporter]

the 3rd step of our 3 layers API (POSIX / Native / Flash) and again we are 
testing what can work

here we will certainly need to add even more Native API to support what can do 
the Flash/AIR API

no brainer example:
in File class, the "exists" property

we just reuse access()  and we are basically done

brainy example:
in File class, the "downloaded" property
eg. "Indicates whether the referenced file or directory was downloaded (from 
the internet) or not."

we don;t have that in POSIX, we have no way to know that with classic 
filesystem API
so we will need to implement systems specific API, depending on what's available

eg. "On systems that do not flag downloaded files, such as Linux, the property 
is not meaningful (and it is set to false)."

Original comment by zwetan on 20 Aug 2014 at 9:39

[GoogleCodeExporter]

one of the difficult part will be to implement the events and there we gonna 
cheat

async methods will be implemented as the non-async one and we will just add 
events as a 1st implementation

on a 2nd pass we will probably try to run them in a different thread or use 
workers

the 3rd pass we will try to hook those events in the EventLoop manager

Original comment by zwetan on 20 Aug 2014 at 9:43

[GoogleCodeExporter]

there are some methods we don't plan to support at all

for ex: browseForDirectory(), in fact all of the browse methods or anything 
that launch a UI

remember we live on the command line, what should be the behaviour of 
browseForDirectory()
when running server side as CGI ?

the simple answer is to simply not support UI and disable those methods

in fact like the AIR doc indicate
"On Android devices, browseForDirectory() is not supported. The File object 
dispatches a cancel event immediately."

we will do the same for such methods

Original comment by zwetan on 20 Aug 2014 at 9:47

[GoogleCodeExporter]

another challenge will be to replicate security limitations and errors

for example:
FileStream open()
can throws a SecurityError
'The file location is in the application directory, and the fileMode parameter 
is set to "append", "update", or "write" mode.'

so first we need to replicate this behaviour, mainly for case where people want 
to use redtamarin to test their code on the command line while expecting to 
have the same behaviour as AIR or Flash (see RuntimeProfile)

but we also need a mechanism that allow to override those limitations and for 
now I think it is something that is also the responsability of the 
RuntimeProfile or maybe a property in the Runtime class directly.

Original comment by zwetan on 20 Aug 2014 at 10:06