On Fri, Sep 2, 2011 at 12:40 PM, Cedric BAIL <[email protected]> wrote: > On Fri, Sep 2, 2011 at 4:56 PM, Gustavo Sverzut Barbieri > <[email protected]> wrote: > > On Fri, Sep 2, 2011 at 10:05 AM, Cedric BAIL <[email protected]> wrote: > >> On Fri, Sep 2, 2011 at 2:45 PM, Leif Middelschulte > >> <[email protected]> wrote: > >>> 2011/9/2 Vincent Torri <[email protected]>: > >>>> On Fri, 2 Sep 2011, Nicolas Aguirre wrote: > >>>>> it does : > >>>>> http://en.wikipedia.org/wiki/Extended_file_attributes#Windows_NT > >>>>> :P > >>>> > >>>> killjoy :) > >>>> > >>>>> > >>>>> 2011/9/2 Iván Briano (Sachiel) <[email protected]>: > >>>>>> > >>>>>> 2011/9/2 Vincent Torri <[email protected]>: > >>>>>>> > >>>>>>> > >>>>>>> On Fri, 2 Sep 2011, Cedric BAIL wrote: > >>>>>>> > >>>>>>>> On Fri, Sep 2, 2011 at 2:29 AM, Gustavo Sverzut Barbieri > >>>>>>>> <[email protected]> wrote: > >>>>>>>>> > >>>>>>>>> Hello all, particularly Cedric. > >>>>>>>>> > >>>>>>>>> Before I explain the annoying problem in consequence of it, let me > >>>>>>>>> say > >>>>>>>>> that I totally disagree with storing playback position in file > >>>>>>>>> xattr. > >>>>>>>>> This kind of thing should be per application, not per file. > >>>>>>>>> 1- Let's say you thumbnail a file using emotion, you'll get file > >>>>>>>>> changed. > >>>>>>>>> 2- Let's say you don't want to remember it. You'll still get file > >>>>>>>>> changed. > >>>>>>>>> 3- You'll be hitting the disc (or flash) more than desired. > >>>>>>>>> > >>>>>>>>> So please remove such thing from Emotion, it's really not there. If > >>>>>>>>> you wish you can make it an optional API call that the application > >>>>>>>>> may > >>>>>>>>> give its own xattr key and it's persisted. But really, any > >>>>>>>>> application > >>>>>>>>> should have its own database as xattr is not available everywhere > >>>>>>>>> and > >>>>>>>>> they will get lots of bugreports with inconsistent behavior. > >>> I agree with cedric here. Why should a player keep track of every file > >>> he ever played or loose info for files on external storages? Why > >>> shouldn't I be able to start watching a movie at home, then move it to > >>> my mobile device and take off, just where I stopped at home? Same goes > >>> for PDFs, etc.. > > > > Are you kidding, right? External storages are usually FAT and so what > > you said makes no sense. > > Today it's possible to find Linux in almost every embedded device, so > using FAT is just usefull for people that don't use Linux as a > Desktop. Mine external storage are XFS, but that doesn't matter for > the current discussion. I also move file on my hard drive. > > > And there are other ways to solve it, let's not get into this > > discussion... all of them the resource is per application and not per > > file. > > It's not a ressource, it's an information about a specific file on the > file system. You want it linked with that file and xattr is the sane > way to link information with a file.
I'm pretty confident to say the information is per application and not per file. As mentioned, if I thumbnail I don't want the position saved. Depending on the context you don't want to use the last position as a starting point. Etc. > >> The PDF application is also a very good example in my opinion. Okular > >> does implement this kind of functionnality by using an XML file in a > >> hidden directory (some kind of database from their point of view). You > >> move the file, you loose the information and a file is leaking on your > >> system. > > > > That's an implementation detail. They should md5/sha1 the relevant > > part of the file (ie: ignore comments and annotations) and consider > > that. Or have something fully integrated to track the moves into the > > system (like Windows or MacOS). > > I dislike both solution. First one for at least two reason, because > computing md5/sha1 take a lot of time to do and also because you need > to track file after you computed it. Typical example of failure for > such an idea is Thumbnail freedesktop standard (agreed they did even > worse than what you propose by calling md5 on the filename), in the > end, their is no link between the file and it's content. Statistically > nothing prevent any collision and their is no way to check if one > occured. More you use this kind of scheme more likely you are to have > weird issue. Ok, it will only be less usable, not a blocking bug, but > still. And the only reason, you have this issue is because you don't > want to link the information directly with the file. > Second solution is even worse, now you add a daemon running > permanently just to track the link between files and information and > you want to do such thing per application ? I seriously don't like > that plan either. Okay, it's better to xattr every second (possibly writing to lots of different blocks it's something like flash systems that care about write-cycles), in every case... hitting error conditions for MMC/SD that are likely formatted as FAT32... Just because of this? IOW: you trash the common case just because of corner cases. Remembering video playback time and resume is not the rule, but the exception. > Their is a mechanism on Linux to link information with a file, and > that's xattr. Their is an equivalent on Windows. Metadata will follow > the file, die with it and you will always have the relevant > information. From my point of view, all this metadata should at some > point get standardized by Freedesktop ( > http://www.freedesktop.org/wiki/CommonExtendedAttributes ). > Now the question is where do you want to put that piece of code, > do you want to move it up in every application that try to display a > video somewhere, or do you want to offer a facility for every one ? I > took the second choice. If you really want it to be moved up. Ok, fair > enough, but from my point of view, you are going to complexify > application for nothing. Each application may do as it want. > And by the way, the bug is fixed without removing the feature. > > > But like I said and Raster agreed, keeping this in Emotion is a NO GO. > > Just remove it, please. > > I still want to ear a argumented answer to mine before I make that choice. The argument is based on use cases. 1 - How many cases do you foresee that are interesting for users to REMEMBER last playback position? Video class/courses? Podcasts? What's more? I can answer with uninteresting cases. DVD playback. Internet clips. Music Video clips. Music from playlists/albums (ie: playing a disc, you listened couple of seconds of some musics and skipped... then when your player starts that music in a sequence it's weird as "what happened to my music? Is it corrupted? Where is the start?!") 2 - How many users expect such feature? AFAIK DVD/BD players don't remember it. Windows don't remember it. Mac doesn't. Some phones have OPTIONS to remember it... and more importantly Youtube does not remember it. If youtube, that have your profile, have the video and all does not remember it... why in earth do you want to do it? You'll get upset users, not happy users. 3 - Do you provide a fallback in the case FS does not support it? Consistent behavior is required. If you want to do xattr, then you must link emotion to eet and keep a parallel database in ~/.config/emotion for media that does not support it... like remote media? fat? systems without xattr (many embedded) 4 - Do you provide a way to opt-out this weird behavior? I've listed lots of uninteresting use cases... Enjoy would opt-out for sure, there is no usefulness in it for a music player. Do you need more arguments? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
