On Sat, Sep 3, 2011 at 4:47 AM, Gustavo Sverzut Barbieri <[email protected]> wrote: > 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.
Yes, and that's the case. Try excessive, when the thumbnail is playing it's not saving the position at all. > Depending on the context you don't want to use the last position as a > starting point. Etc. Yes, but the way the information must be cross application. Policy is an application decision, information should be shared across application. >> >> 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? Are you thinking I am crazy ? Did you read the code at least ? In emotion_test, it save this information on exit. In excessive it save it when you close the video player. That's one request to write per video played in the player state. And it's up to the application to do what it want with that information. Does enjoy trigger that path ? Answer is no. > IOW: you trash the common case just because of corner cases. > Remembering video playback time and resume is not the rule, but the > exception. GNI ? Seriously read the code ! It all up to the application to ask this information and save it. So if you consider it's a corner case, that's fine the application will just never retrieve nor save it, so it will never be in your code path. >> 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. Of course, but bringing standard way to share information across application help. >> 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? When I get interrupted watching a video. It could be a pretty common case for video, but who cares. > 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?!") Are you using enjoy ? Did it have this behaviour ? You don't even need to read the code, just test it at least ! This discussion is completly useless, you didn't read the code to start with and are complaining about behaviour and code that don't exist. > 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. That's up to the application, but on a tablet/phone/netbook, I most of the time don't have enought time to watch an entire video. And yes, it's not a Youtube use case. I know set top box and media player that provide this feature by default, same for tablet and apparently for phone to. As for DVD/BD player, they are a thing of the past for me, so I don't know what they can do, nor do I care. > 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. It's an opt-in feature... try enjoy... > Do you need more arguments? You are good at arguing without actually RTFM^WC ! Test enjoy, read the code, understand it and then we can discuss on the current implementation. It's completely moot for me to argument with you at the moment, when you don't take the time to actually read what I write, read the code or at least test application. -- Cedric BAIL ------------------------------------------------------------------------------ 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
