On Mon, 8 Jan 2018 10:40:13 -0200 Gustavo Sverzut Barbieri <[email protected]> said:
> On Mon, Jan 8, 2018 at 4:40 AM, Jean-Philippe André <[email protected]> wrote: > >> Efl.File -> Efl.Io.File > >> > > > > This name makes sense > > But I already see an Efl.Io.File class? Gustavo, any input here? > > Efl.Io refers to actual I/O (open, read, write, close...) while Efl.File is > > just for the (image/edje) file set/get. > > IMO Efl.File should go, but it's not that simple in practice. > > The idea was to create a virtualized file for access, like Glib, Qt > and all other frameworks allow... File in a ZIP? File in a FTP server? > no worries! it will handle. > > except that everyone else virtualizes access: virtual open, close, > size get, read, write... which can be translated to various > protocols/formats (zip, ftp, http, ssh...), with some handling caches > for you (ie: download cache) > > Efl.File and associated, like vpath, would actually create a local > file for you, so all file operations would work, but just immutable > were allowed (ie: no write, as it wouldn't reflect in the actual > target). > > for things like emile and image loaders, it's very simple replacement: > all they dealt with were files, receiving a path... so changing to > eina.file was no-brainer... > > however, ideally these would have better API and dynamic lifecycle... > such as progressive/partial loading with JPEG (monitoring "can_read" > to get more data until "eos"). Not to say we still miss a cache > mechanism, for zip wouldn't need to cache, but for remote access could > use like HTTP Last-Modified/If-Modified-Since, Etag/If-None-Match... > respect Expiry, store in local files, like done for web runtimes). > > TL;DR: it should but won't go away, so this virtualized file should be > renamed, however I have no suggestions as I'm bad at names :-) i think we need a virtualized file object/class thing. mostly to implement async file ops like directory listing, statting of file content, even checking mime magic and even doing extra metadata work like thumbnail creation and so on. to me such a class and set of objects mirror the real filesystem (obj per dir and file) and just do the whole async file io for you and all you do it say "being listing ... perhaps with sort mode X" and then you get update events as the dir is scanned and sorted. (so you can display incrementally - this is what efm does in e as it lists and then sorts and re-sorts as it lists more, for example). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
