On Sun, Sep 4, 2011 at 9:01 AM, Cedric BAIL <cedric.b...@free.fr> wrote: > On Sat, Sep 3, 2011 at 4:47 AM, Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> wrote: >> On Fri, Sep 2, 2011 at 12:40 PM, Cedric BAIL <cedric.b...@free.fr> wrote: >>> On Fri, Sep 2, 2011 at 4:56 PM, Gustavo Sverzut Barbieri >>> <barbi...@profusion.mobi> wrote: >>> > On Fri, Sep 2, 2011 at 10:05 AM, Cedric BAIL <cedric.b...@free.fr> wrote: >>> >> On Fri, Sep 2, 2011 at 2:45 PM, Leif Middelschulte >>> >> <leif.middelschu...@gmail.com> wrote: >>> >>> 2011/9/2 Vincent Torri <vto...@univ-evry.fr>: >>> >>>> 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) <sachi...@gmail.com>: >>> >>>>>> >>> >>>>>> 2011/9/2 Vincent Torri <vto...@univ-evry.fr>: >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> On Fri, 2 Sep 2011, Cedric BAIL wrote: >>> >>>>>>> >>> >>>>>>>> On Fri, Sep 2, 2011 at 2:29 AM, Gustavo Sverzut Barbieri >>> >>>>>>>> <barbi...@profusion.mobi> 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.
I did not had it here. Installed. Tested. Indeed does not save... that's good. :-) >> 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. Zzzz... cross platform? Since when? Depends on optional kernel features. I'm for one disable it in most embedded systems I have. Not cross platform. Moot point. >>> >> 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. How does the application knows it failed and needs to provide fallback? No API. You don't provide the automatic fallback either. The required code on your side is 2-3 lines less than the proposed stuff that goes in Eio to simplify development. Then I consider this even less interesting. >>> 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. Yeah, I don't. I pause the video... that's what pause is for, no? >> 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. my bad... but given the bugs that hit me so far I was shooting everyone that is linked with Emotion and Xattr! :-D Now tell me that the code wasn't buggy? You patched it so it works ;-) >> 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. Tablets and phone basically have external database with other computed stuff (title, artist, play length, thumbnail, indexes...). They must have this because they're often reading from FAT MMC/SD or their own internal memory is exported to PC as mass storage using USB... PC is windows, so FAT as well. Moreover, they must have external database for metadata if they want to be any fast. They need to hit one single file and get all the information they need, ready, ASAP. They can't open file and request ID3v2, they can't check for thumbnails and request their generation... DB is the best option here, also offers filter, tags, etc. >> 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. Indeed I did not test it with enjoy, but emotion_test and given the bug that hit me at the time I wondered that. I skimmed the API and saw 2 calls to optionally do that... as you have to call it, and given my prior arguments... this is totally useless and fixing the problem in the wrong place. See my other thread on making Eio easier (number of calls would be basically the same as in your case)... But it still have broken consistency I'd want solved in one application. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
