Re: Module Proposal: Rygel
Hi, On Fri, Mar 19, 2010 at 5:53 PM, Vincent Untz vu...@gnome.org wrote: Le vendredi 19 mars 2010, à 16:39 +0200, Zeeshan Ali (Khattak) a écrit : I didn't miss that. :) If you read carefully he said just to be safe and hence it's not so important. Still, I tried to setup the I said on the safe side because I've no good example of when those strings would appear. But I would expect them to be translatable :-) translation framework, got into some weird autofoo issues, asked some gnome developers (including you) to help me out on IRC and when nobody replied, I gave-up and started working on something more useful: unit tests. Do you have a bug report somewhere with the issues that you had? I didn't see your request for help on irc, and I'm sure many people didn't. Just to inform the interested people that Rygel in git master now has the translation framework fixed and I've marked all strings (that could ever be seen by user) for translation. Thanks to Andre Klapper and Pierre-Luc for helping out on this. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi, On Mon, Feb 22, 2010 at 4:17 PM, Vincent Untz vu...@gnome.org wrote: We have pride in our incredible translation teams; it would be really nice if Rygel had the infrastructure in place to be translated. Is this planned? It most certainly is and if it starts to become very likely that my proposal will be approved, I'll put this in my high-priority todo list. Heh, the logic should be reversed :-) It can't be approved (or likely to be approved) until the app is translatable. Since me and Bastien (based on Lennart's arguments on this thread) agreed to kill the preferences UI in favor of some simple options to be added to gnome-user-share dialog, do I still need to do this for my proposal to be considered? -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Zeeshan Ali (Khattak) wrote: Heh, the logic should be reversed :-) It can't be approved (or likely to be approved) until the app is translatable. Since me and Bastien (based on Lennart's arguments on this thread) agreed to kill the preferences UI in favor of some simple options to be added to gnome-user-share dialog, do I still need to do this for my proposal to be considered? In another branch of this thread, Vincent Untz gave you an answer: | Yeah something like that. However most of the errors/warnings are | sent over to the (remote) client as well and it all depends on the | client whether it shows them to user or not. | | In this case, it probably makes sense to have them translated, to be | on the safe side. And that makes me think the preferences UI was not all there was to Rygel, other parts should be translatable as well. Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On 19/03/10 12:59, Bastien Nocera wrote: On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: 2 things come to mind: - Tracker shouldn't need to use D-Bus to access its database read-only: https://bugzilla.gnome.org/show_bug.cgi?id=613255 Well, D-Bus provides a single entry point for any requests to the data. If we then provide some direct access using a library, that complicates things further. At this point we are not threaded, however, we are currently looking into the possibility of doing this due to recent events. What is so bad about using D-Bus? What is the relevance of read-only? -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 13:36 +, Martyn Russell wrote: On 19/03/10 12:59, Bastien Nocera wrote: On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: 2 things come to mind: - Tracker shouldn't need to use D-Bus to access its database read-only: https://bugzilla.gnome.org/show_bug.cgi?id=613255 Well, D-Bus provides a single entry point for any requests to the data. If we then provide some direct access using a library, that complicates things further. At this point we are not threaded, however, we are currently looking into the possibility of doing this due to recent events. What is so bad about using D-Bus? See the original mail. It's pushing data over D-Bus that already went through the bus in a different form. What is the relevance of read-only? I don't understand the question, or how it relates to the point I was making. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 13:36 +, Martyn Russell wrote: On 19/03/10 12:59, Bastien Nocera wrote: On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: 2 things come to mind: - Tracker shouldn't need to use D-Bus to access its database read-only: https://bugzilla.gnome.org/show_bug.cgi?id=613255 Well, D-Bus provides a single entry point for any requests to the data. If we then provide some direct access using a library, that complicates things further. At this point we are not threaded, however, we are currently looking into the possibility of doing this due to recent events. What is so bad about using D-Bus? Perhaps the fact that D-Bus wasn't meant as a super fast-IPC and the fact that having to do two task switches + all the associated wire overhead to retrieve a piece of data will be quite slow? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi, On Fri, Mar 19, 2010 at 2:56 PM, Frederic Peters fpet...@gnome.org wrote: Zeeshan Ali (Khattak) wrote: Heh, the logic should be reversed :-) It can't be approved (or likely to be approved) until the app is translatable. Since me and Bastien (based on Lennart's arguments on this thread) agreed to kill the preferences UI in favor of some simple options to be added to gnome-user-share dialog, do I still need to do this for my proposal to be considered? In another branch of this thread, Vincent Untz gave you an answer: | Yeah something like that. However most of the errors/warnings are | sent over to the (remote) client as well and it all depends on the | client whether it shows them to user or not. | | In this case, it probably makes sense to have them translated, to be | on the safe side. And that makes me think the preferences UI was not all there was to Rygel, other parts should be translatable as well. I didn't miss that. :) If you read carefully he said just to be safe and hence it's not so important. Still, I tried to setup the translation framework, got into some weird autofoo issues, asked some gnome developers (including you) to help me out on IRC and when nobody replied, I gave-up and started working on something more useful: unit tests. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 P.S. In case you are interested, here is my attempt: http://gitorious.org/rygel/rygel/commits/l10n ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Le vendredi 19 mars 2010, à 16:39 +0200, Zeeshan Ali (Khattak) a écrit : I didn't miss that. :) If you read carefully he said just to be safe and hence it's not so important. Still, I tried to setup the I said on the safe side because I've no good example of when those strings would appear. But I would expect them to be translatable :-) translation framework, got into some weird autofoo issues, asked some gnome developers (including you) to help me out on IRC and when nobody replied, I gave-up and started working on something more useful: unit tests. Do you have a bug report somewhere with the issues that you had? I didn't see your request for help on irc, and I'm sure many people didn't. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi Bastien, On Fri, Mar 19, 2010 at 2:59 PM, Bastien Nocera had...@hadess.net wrote: 2 things come to mind: - Tracker shouldn't need to use D-Bus to access its database read-only: https://bugzilla.gnome.org/show_bug.cgi?id=613255 I couldn't agree more. So here is my plan: I will go with all plugin[1] external approach using the new D-Bus spec[2] . This will mean SLOW (its already very slow with my queries that has lots of optionals) tracker backend but I leave that for tracker guys to solve. They can either do what you asked for above or they can implement this D-Bus interface directly. - The way you currently use Tracker means that there's no way to differentiate between videos that I want indexed and searchable, and the ones that I want to export. This is a privacy problem and could be solved by making applications provide their catalogues instead (which could be powered by Tracker). Actually this issue is partly solved. I made sure that tracker guys have the right ontology caugh..metadata keys for this. However, there is currently no UI for user to be able to mark media to be exported. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 [1] Except the ones that serve gstreamer source elements hence must be in-process but these are developer/test oriented. [2] http://live.gnome.org/Rygel/MediaServer2Spec ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, Mar 19, 2010 at 4:53 PM, Vincent Untz vu...@gnome.org wrote: Le vendredi 19 mars 2010, à 16:39 +0200, Zeeshan Ali (Khattak) a écrit : I didn't miss that. :) If you read carefully he said just to be safe and hence it's not so important. Still, I tried to setup the I said on the safe side because I've no good example of when those strings would appear. But I would expect them to be translatable :-) These are error messages mostly what gnome apps/libs spew out on console using g_critical/warning/error functions. translation framework, got into some weird autofoo issues, asked some gnome developers (including you) to help me out on IRC and when nobody replied, I gave-up and started working on something more useful: unit tests. Do you have a bug report somewhere with the issues that you had? No but I can file a bug report and assign it to you if you like. :) Try building that rygel branch i linked to and you'll see what the problem is. If you feel lazy, just ping me in private on irc and I'll provide the details of the issue. I didn't see your request for help on irc, and I'm sure many people didn't. Thats ok, people have better things to do. :) Just to be clear, I didn't mean to insult anyone, was just telling my excuse. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Le vendredi 19 mars 2010, à 17:17 +0200, Zeeshan Ali (Khattak) a écrit : On Fri, Mar 19, 2010 at 4:53 PM, Vincent Untz vu...@gnome.org wrote: I didn't see your request for help on irc, and I'm sure many people didn't. Thats ok, people have better things to do. :) Just to be clear, I didn't mean to insult anyone, was just telling my excuse. :) Oh sure, there was no insult. My point was that if nobody can help you at a given time on irc, then it doesn't mean it's impossible to do ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On 19/03/10 13:56, Bastien Nocera wrote: On Fri, 2010-03-19 at 13:36 +, Martyn Russell wrote: On 19/03/10 12:59, Bastien Nocera wrote: On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: 2 things come to mind: - Tracker shouldn't need to use D-Bus to access its database read-only: https://bugzilla.gnome.org/show_bug.cgi?id=613255 Well, D-Bus provides a single entry point for any requests to the data. If we then provide some direct access using a library, that complicates things further. At this point we are not threaded, however, we are currently looking into the possibility of doing this due to recent events. What is so bad about using D-Bus? See the original mail. It's pushing data over D-Bus that already went through the bus in a different form. What is the relevance of read-only? I don't understand the question, or how it relates to the point I was making. What I mean is, what difference does it make if the data is readonly or readwrite? Surely applications would want ONE method not two for communicating with Tracker's. Or did I misunderstand somehow? -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On 19/03/10 13:56, Bastien Nocera wrote: On Fri, 2010-03-19 at 13:36 +, Martyn Russell wrote: Well, D-Bus provides a single entry point for any requests to the data. If we then provide some direct access using a library, that complicates things further. At this point we are not threaded, however, we are currently looking into the possibility of doing this due to recent events. What is so bad about using D-Bus? See the original mail. It's pushing data over D-Bus that already went through the bus in a different form. Ah I see your point now. Even at this point there is no direct access API to Tracker, it is all done over d-bus. Performance wise, we don't have problems generally. Perhaps this is a reason to seriously consider a direct access library. I don't think it will happen before 0.8 however. -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 16:56 +0200, Zeeshan Ali (Khattak) wrote: [CUT] Short note on... Actually this issue is partly solved. I made sure that tracker guys have the right ontology caugh..metadata keys Let's just call these things ontologies. That's just what everybody in RDF calls it. And those alternative versions of the word like the metadata keys, the fields, the schema, description of the things ... are just confusing. It's called an ontology. It wont hurt you. It wont rot your brain. It's terminology that everybody in RDF uses. Let's get over it. Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 15:25 +, Martyn Russell wrote: On 19/03/10 13:56, Bastien Nocera wrote: On Fri, 2010-03-19 at 13:36 +, Martyn Russell wrote: On 19/03/10 12:59, Bastien Nocera wrote: On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: 2 things come to mind: - Tracker shouldn't need to use D-Bus to access its database read-only: https://bugzilla.gnome.org/show_bug.cgi?id=613255 Well, D-Bus provides a single entry point for any requests to the data. If we then provide some direct access using a library, that complicates things further. At this point we are not threaded, however, we are currently looking into the possibility of doing this due to recent events. What is so bad about using D-Bus? See the original mail. It's pushing data over D-Bus that already went through the bus in a different form. What is the relevance of read-only? I don't understand the question, or how it relates to the point I was making. What I mean is, what difference does it make if the data is readonly or readwrite? I'm mentioning read-only because I believe it would be possible to implement with your current architecture. If you want read/write access, it would probably involve file locking, and all sort of nastiness that I understand might be problematic. Reading the data through a native API instead of through D-Bus would mean being able to shift very large amounts of data without the marshalling/demarshalling (say, loading 100k audio tracks' metadata would probably take a large amount of time over D-Bus, where it would be of negligeable duration through a more direct API). Surely applications would want ONE method not two for communicating with Tracker's. Or did I misunderstand somehow? This would all be hidden behind the tracker libraries for most developers, so it shouldn't matter. You'd get the same result, just much faster. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 12:59 +, Bastien Nocera wrote: On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: Hi, 2 things come to mind: - Tracker shouldn't need to use D-Bus to access its database read-only: https://bugzilla.gnome.org/show_bug.cgi?id=613255 This isn't as easy at it sounds, I posted a comment on the bug you reported explaining what the difficulty is. https://bugzilla.gnome.org/show_bug.cgi?id=613255#c1 Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Fri, 2010-03-19 at 16:28 +, Bastien Nocera wrote: On Fri, 2010-03-19 at 15:25 +, Martyn Russell wrote: I tried to sent this several times, but it looks like GMANE is not working for me today ... And Evolution has its reply to all feature all wrong too, apparently. [CUT] What I mean is, what difference does it make if the data is readonly or readwrite? I'm mentioning read-only because I believe it would be possible to implement with your current architecture. If you want read/write access, it would probably involve file locking, and all sort of nastiness that I understand might be problematic. Reading the data through a native API instead of through D-Bus would mean being able to shift very large amounts of data without the marshalling/demarshalling (say, loading 100k audio tracks' metadata would probably take a large amount of time over D-Bus, where it would be of negligeable duration through a more direct API). This isn't as easy at it sounds, I posted a comment on the bug you reported explaining what the difficulty is. https://bugzilla.gnome.org/show_bug.cgi?id=613255#c1 Surely applications would want ONE method not two for communicating with Tracker's. Or did I misunderstand somehow? This would all be hidden behind the tracker libraries for most developers, so it shouldn't matter. You'd get the same result, just much faster. Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi, On Sat, Feb 20, 2010 at 11:57 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: * Rygel is already readily available in two major distributions: Debian and Fedora. Now it's also available in Ubuntu (lucid). Its also available in an unofficial Gentoo repo: http://gpo.zugaina.org/net-misc/rygel -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Samba is software for big installations, and primarily used on non-desktop servers. Well, it _serves_ files, so it is natural to expect it to be on servers. But I do not know what exactly positions it as for big installations. Samba is found in set-top-boxes, on mobile devices (I just seen it on n810) etc. tbh I'd find it quite useful if we could run samba from inside a user session too, the same way we can run apache in it for gnome-user-share. I am quite happy that samba does not provide that feature (I suspect there might be some issue with sharing tcp ports). There is no need to create many processes where one process can do everything. Think Occam's razor;) It would be kinda weird if a system Rygel would share the audio streams of a user PulseAudio instance. Why not? Is it a technical issue or architectural? Sorry, I am not familiar with the PA internals, so some details would be nice to have... Actually, it was already mentioned that Rygel can run as system service - so I assume that feature is already available? Or not? That sounds like a pretty weak argument, of the Unix nostalgia kind. That is not an argument as such, I am just showing where I come from. The primary values, so to say:) Yes, I like the true and proven ways of good old Unix, and consider it architecturally suspicious where people ignore them without very serious reason (well, at least I feel obliged to question the reasons and challenge them:). Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Zeeshan Ali (Khattak) wrote: Adoption GNOME-ness, community: We have pride in our incredible translation teams; it would be really nice if Rygel had the infrastructure in place to be translated. Is this planned? Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, Feb 22, 2010 at 01:51:50AM +0200, Zeeshan Ali (Khattak) wrote: On Sat, Feb 20, 2010 at 11:57 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: What is it? I hate unneeded redundancy so I'll just ask you to read the home page: http://live.gnome.org/Rygel pbor pointed out on IRC that I didn't really have a nice description on the homepage so I corrected that. Please check it out if you didn't understand what rygel is all about. :) From reading description, it seems to me that Rygel would be better suited as system service. Just like for example mt-daapd (which seem to have the same purpose as Rygel but for DAAP). How does it fit GNOME? -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
From reading description, it seems to me that Rygel would be better suited as system service. Just like for example mt-daapd (which seem to have the same purpose as Rygel but for DAAP). How does it fit GNOME? Absolutely correct point! Folks, when did you decided that GNOME is for PCs only (personal computers, in the worst of all possible interpretations - computer for one single user)? That is ok for tablets, smartphones etc - but not for general purpose desktop. If some computer provides media collection through UPnP/DAAP, it should do it as a system-level service, just like mt-daapd (even though it can be flexible enough to accomodate per-user dirs, just like apache or smb). Cheers, Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi, On Mon, Feb 22, 2010 at 2:08 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: From reading description, it seems to me that Rygel would be better suited as system service. Just like for example mt-daapd (which seem to have the same purpose as Rygel but for DAAP). How does it fit GNOME? Absolutely correct point! Folks, when did you decided that GNOME is for PCs only (personal computers, in the worst of all possible interpretations - computer for one single user)? That is ok for tablets, smartphones etc - but not for general purpose desktop. We didn't make any such decision, actually it's just the other way around. See below. If some computer provides media collection through UPnP/DAAP, it should do it as a system-level service, just like mt-daapd (even though it can be flexible enough to accomodate per-user dirs, just like apache or smb). Just because others do it in a particular way, doesn't make it right. Although Rygel can be run as a system-wide service, the main target use-case is that of providing services per-user[1] so for example each user can choose to share his media on the network rather than every user's media. We want *each* user to have full control of whether she wants UPnP services to be enabled or not and then which services exactly she wants and what exactly she wants from it using a simple preferences UI. Lets assume for a second that we want rygel to run as a system-service, how does rygel then communicate to processes running on session-bus (e.g tracker, rhythmbox, totem)? Lastly, rygel can be run as both system-wide service and per-session at the same time on the same machine. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 [1] Currently it's actually per-session because of D-Bus limitation but plan is to make it per-user when it's possible. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi Frederic! On Mon, Feb 22, 2010 at 9:59 AM, Frederic Peters fpet...@gnome.org wrote: Zeeshan Ali (Khattak) wrote: Adoption GNOME-ness, community: We have pride in our incredible translation teams; it would be really nice if Rygel had the infrastructure in place to be translated. Is this planned? It most certainly is and if it starts to become very likely that my proposal will be approved, I'll put this in my high-priority todo list. The preferences UI case is easy but I was wondering what to do about the actual rygel process. Do I need translations there? I ask since that will be mostly invisible to a typical user. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Am Sonntag, den 21.02.2010, 18:12 +0200 schrieb Zeeshan Ali: I agree but I really suck at UIs You could ask for a review on the usability mailing list. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi, On Mon, Feb 22, 2010 at 4:17 PM, Vincent Untz vu...@gnome.org wrote: It most certainly is and if it starts to become very likely that my proposal will be approved, I'll put this in my high-priority todo list. Heh, the logic should be reversed :-) It can't be approved (or likely to be approved) until the app is translatable. Gotcha! I'll see what I can do this week about it. The preferences UI case is easy but I was wondering what to do about the actual rygel process. Do I need translations there? I ask since that will be mostly invisible to a typical user. Where will the strings appear? If it's just error strings in a log file, then they don't have to be translated, for example. Yeah something like that. However most of the errors/warnings are sent over to the (remote) client as well and it all depends on the client whether it shows them to user or not. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Le lundi 22 février 2010, à 16:23 +0200, Zeeshan Ali (Khattak) a écrit : On Mon, Feb 22, 2010 at 4:17 PM, Vincent Untz vu...@gnome.org wrote: Where will the strings appear? If it's just error strings in a log file, then they don't have to be translated, for example. Yeah something like that. However most of the errors/warnings are sent over to the (remote) client as well and it all depends on the client whether it shows them to user or not. In this case, it probably makes sense to have them translated, to be on the safe side. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Just because others do it in a particular way, doesn't make it right. Although Rygel can be run as a system-wide service, the main target use-case is that of providing services per-user[1] so for example each user can choose to share his media on the network rather than every user's media. That use case is perfectly served by samba - having ONE system-level daemon and multiple per-user shared directories (controlled by users) We want *each* user to have full control of whether she wants UPnP services to be enabled or not and then which services exactly she wants and what exactly she wants from it using a simple preferences UI. I do not see any trouble with that. That is absolutely valid requirement - except I'd replace each user with each user belonging to some group ;) Lets assume for a second that we want rygel to run as a system-service, how does rygel then communicate to processes running on session-bus (e.g tracker, rhythmbox, totem)? AFAIK the typical model is working the other way around. If these process have anything to say to system-level daemons, they initiate communications. CMIIW. Why is that model bad for Rygel? Lastly, rygel can be run as both system-wide service and per-session at the same time on the same machine. That is a very important thing to know. In that case, I still have a couple of questions: - Should gnome promote per-session usage of Rygel (in case of adoption), as more desktop-oriented mode of operation - or should gnome be neutral in that aspect? - What's the general approach for system-wide services in gnome? Does GNOME need that kind of policy?Some system-wide services are really useful for desktop, would GNOME adopt them? Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi, On Mon, Feb 22, 2010 at 4:29 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: Just because others do it in a particular way, doesn't make it right. Although Rygel can be run as a system-wide service, the main target use-case is that of providing services per-user[1] so for example each user can choose to share his media on the network rather than every user's media. That use case is perfectly served by samba - having ONE system-level daemon and multiple per-user shared directories (controlled by users) Not really. Can the user share his directories if the system-wide deamon is not running? Sure, if the user has admin privileges she is asked for the authentication and is able to start samba daemon but we can't assume each user has the admin rights. We want *each* user to have full control of whether she wants UPnP services to be enabled or not and then which services exactly she wants and what exactly she wants from it using a simple preferences UI. I do not see any trouble with that. That is absolutely valid requirement - except I'd replace each user with each user belonging to some group ;) That is because you seem to be keen on admin intervention while I am keen on each user to be as free (from admin) as possible. :) Lets assume for a second that we want rygel to run as a system-service, how does rygel then communicate to processes running on session-bus (e.g tracker, rhythmbox, totem)? AFAIK the typical model is working the other way around. If these process have anything to say to system-level daemons, they initiate communications. CMIIW. Why is that model bad for Rygel? Because it's Rygel that starts the communication being the client. Also if we go the route you are recommending, each such application will present user configuration in it's own UI and there will be no centralized place for user to control his DLNA (media sharing playback) preferences. Lastly, rygel can be run as both system-wide service and per-session at the same time on the same machine. That is a very important thing to know. In that case, I still have a couple of questions: - Should gnome promote per-session usage of Rygel (in case of adoption), as more desktop-oriented mode of operation - or should gnome be neutral in that aspect? - What's the general approach for system-wide services in gnome? Does GNOME need that kind of policy?Some system-wide services are really useful for desktop, would GNOME adopt them? I don't think I alone can answer these questions and in this case I shouldn't say anything being biased. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, 22.02.10 09:13, Tomasz Torcz (to...@pipebreaker.pl) wrote: I hate unneeded redundancy so I'll just ask you to read the home page: http://live.gnome.org/Rygel pbor pointed out on IRC that I didn't really have a nice description on the homepage so I corrected that. Please check it out if you didn't understand what rygel is all about. :) From reading description, it seems to me that Rygel would be better suited as system service. Just like for example mt-daapd (which seem to have the same purpose as Rygel but for DAAP). How does it fit GNOME? I strongly disagree. Sharing user files should be a job for user processes. Why? First of all, the directory is called ~/Music, not /srv/music. You certainly don't want to have all this permission madness that you need to deal with if you run a file server like that as a system service. User file sharing should live in the user session. Also, look at the examples of bluetooth/obex and gnome-user-share. I think one should carefully distuingish between desktop file sharing and server file sharing. By desktop file sharing I mean file sharing enabled and configured by a normal user, who has a local account, and wants to quickly share files from within his active session. And as such this kind of file sharing should also run under his user ID, and follow his own access permissions (and that is actually the most important issue). UPnP A/V is certainly not a protocol datacenters will depend on, it is simply something that is handy on a peer-to-peer network of user desktops. And due to that the desktop file sharing model is generally more applicable to it then the server file sharing model. The only drawback of running file sharing services like this inside the normal user session is of course that files are not shared when the user isn't logged in. But that is something we need to fix in the bigger picture. We should not blame Rygel for the fact that there is no real infrastructure for running user daemons outside of a session. But I am sure this can and will be fixed eventually. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, 22.02.10 12:08, Sergey Udaltsov (sergey.udalt...@gmail.com) wrote: From reading description, it seems to me that Rygel would be better suited as system service. Just like for example mt-daapd (which seem to have the same purpose as Rygel but for DAAP). How does it fit GNOME? Absolutely correct point! Folks, when did you decided that GNOME is for PCs only (personal computers, in the worst of all possible interpretations - computer for one single user)? That is ok for tablets, smartphones etc - but not for general purpose desktop. If some computer provides media collection through UPnP/DAAP, it should do it as a system-level service, just like mt-daapd (even though it can be flexible enough to accomodate per-user dirs, just like apache or smb). Well, we already run apache as part of the user session from gnome-user-share. GNOME is certainly focussed on the desktop, or similar user interfaces. As such it should provide services for building user interfaces, not server machines. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Sorry for being unclear. Sure I know the difference between UPnP and CIFS. I am just saying that approach (I incorrectly called it use case) single system-level daemon + multiple user-controlled user-specific resources looks architecturally better than multiple user-level daemons. Sergey PS My Popcorn Hour can do both CIFS and UPnP, and I use CIFS :P On Mon, Feb 22, 2010 at 4:05 PM, Ross Burton r...@burtonini.com wrote: On Mon, 2010-02-22 at 14:29 +, Sergey Udaltsov wrote: Just because others do it in a particular way, doesn't make it right. Although Rygel can be run as a system-wide service, the main target use-case is that of providing services per-user[1] so for example each user can choose to share his media on the network rather than every user's media. That use case is perfectly served by samba - having ONE system-level daemon and multiple per-user shared directories (controlled by users) I wasn't aware that my Bravia TV or Roku SoundBridge could play from CIFS shares, I thought they were DLNA players, but thanks for informing me of this fact. Yes, I'm being sarcastic. Rygel is a DNLA media server, not a generic file server, samba doesn't perfectly serve the role of media server. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, 22.02.10 14:29, Sergey Udaltsov (sergey.udalt...@gmail.com) wrote: Just because others do it in a particular way, doesn't make it right. Although Rygel can be run as a system-wide service, the main target use-case is that of providing services per-user[1] so for example each user can choose to share his media on the network rather than every user's media. That use case is perfectly served by samba - having ONE system-level daemon and multiple per-user shared directories (controlled by users) Samba is software for big installations, and primarily used on non-desktop servers. tbh I'd find it quite useful if we could run samba from inside a user session too, the same way we can run apache in it for gnome-user-share. Lets assume for a second that we want rygel to run as a system-service, how does rygel then communicate to processes running on session-bus (e.g tracker, rhythmbox, totem)? AFAIK the typical model is working the other way around. If these process have anything to say to system-level daemons, they initiate communications. CMIIW. Why is that model bad for Rygel? It would be kinda weird if a system Rygel would share the audio streams of a user PulseAudio instance. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, 2010-02-22 at 14:29 +, Sergey Udaltsov wrote: Just because others do it in a particular way, doesn't make it right. Although Rygel can be run as a system-wide service, the main target use-case is that of providing services per-user[1] so for example each user can choose to share his media on the network rather than every user's media. That use case is perfectly served by samba - having ONE system-level daemon and multiple per-user shared directories (controlled by users) I wasn't aware that my Bravia TV or Roku SoundBridge could play from CIFS shares, I thought they were DLNA players, but thanks for informing me of this fact. Yes, I'm being sarcastic. Rygel is a DNLA media server, not a generic file server, samba doesn't perfectly serve the role of media server. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, 22.02.10 15:27, Sergey Udaltsov (sergey.udalt...@gmail.com) wrote: That is because you seem to be keen on admin intervention while I am keen on each user to be as free (from admin) as possible. :) I do not really care about admin intervention, honestly. I just prefer to have a single server process on my system, regardless of the number of users. That sounds like a pretty weak argument, of the Unix nostalgia kind. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Sun, 21.02.10 14:50, Bastien Nocera (had...@hadess.net) wrote: - The preferences UI is pretty horrible Should we really keep the UI at all? The options offered therein appear very esoteric to me, and a trivial addition to gnome-file-share-properties that would just introduce one simple checkbox Share my Music (and Share my Videos, yadda yadda) seems a lot more appropriate to me. I don't see why anybody would want to disable transcoding or choose the interface to listen on (Rygel should listen on all of them anyway...). And the plugins pane of rygel preferences is redundant too. Rygel should use tracker if it is installed and otherwise and automatically fall back to the gvfs backend. No need to configure anything there. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi, On Mon, Feb 22, 2010 at 6:29 PM, Lennart Poettering mzta...@0pointer.de wrote: On Sun, 21.02.10 14:50, Bastien Nocera (had...@hadess.net) wrote: - The preferences UI is pretty horrible Should we really keep the UI at all? The options offered therein appear very esoteric to me, and a trivial addition to gnome-file-share-properties that would just introduce one simple checkbox Share my Music (and Share my Videos, yadda yadda) seems a lot more appropriate to me. Hmm.. sounds right now that I looked at that UI. I don't see why anybody would want to disable transcoding or choose the interface to listen on (Rygel should listen on all of them anyway...). Agree on transcoding but not interfaces. We don't want media to be shared on public networks. The plan is to be able to select network by ESSID so user can decide where the media is shared (home) and where its not (office, cafe). Unless there is a better way to achieve this? And the plugins pane of rygel preferences is redundant too. Rygel should use tracker if it is installed and otherwise and automatically fall back to the gvfs backend. No need to configure anything there. Agreed! So I guess we both agree on getting rid of this UI mostly and move the remaining parts to gnome-user-share UI. Now lets see if Bastien agrees. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
2010/2/22 Lennart Poettering mzta...@0pointer.de: Well, we already run apache as part of the user session from gnome-user-share. GNOME is certainly focussed on the desktop, or similar user interfaces. As such it should provide services for building user interfaces, not server machines. A bit OT but I'd like to mention the meiga project [1] here. It uses libsoup instead apache to share your directories. Regards, [1] http://meiga.igalia.com/ -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, 22.02.10 19:05, Zeeshan Ali (Khattak) (zee...@gmail.com) wrote: Should we really keep the UI at all? The options offered therein appear very esoteric to me, and a trivial addition to gnome-file-share-properties that would just introduce one simple checkbox Share my Music (and Share my Videos, yadda yadda) seems a lot more appropriate to me. Hmm.. sounds right now that I looked at that UI. I don't see why anybody would want to disable transcoding or choose the interface to listen on (Rygel should listen on all of them anyway...). Agree on transcoding but not interfaces. We don't want media to be shared on public networks. The plan is to be able to select network by ESSID so user can decide where the media is shared (home) and where its not (office, cafe). Unless there is a better way to achieve this? Oh, please don't. This is absolutely nothing you should try to hack into Rygel. This needs to be implemented system-wide as a simple firewall/profile selection thing, possibly in networkmanager where you can choose from three simple profiles (home, work, cafe, i.e. trusted, semi-trusted, not trusted at all, and whateever other profile an admin might want to add in addition to those). You certainly don't seperate subsystems that enable/disable rygel and apache+webdav+avahi independently. Also, the ESSID is unsuitable for authentication. We don't do this for g-u-s/apache either. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi, 2010/2/22 Javier Jardón jjar...@gnome.org: 2010/2/22 Lennart Poettering mzta...@0pointer.de: Well, we already run apache as part of the user session from gnome-user-share. GNOME is certainly focussed on the desktop, or similar user interfaces. As such it should provide services for building user interfaces, not server machines. A bit OT but I'd like to mention the meiga project [1] here. It uses libsoup instead apache to share your directories. While that is definitely a big + point (amongst others) in favor of meiga, gnome-user-share is part of GNOME so I would like to depend on that. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Le lundi 22 février 2010 à 17:21 +0100, Lennart Poettering a écrit : I do not really care about admin intervention, honestly. I just prefer to have a single server process on my system, regardless of the number of users. That sounds like a pretty weak argument, of the Unix nostalgia kind. And ironically, this is the kind of nostalgia that makes life harder for people who administer large environments. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
Hi, - Original message - The only comments I would make are: - The preferences UI is pretty horrible I agree but I really suck at UIs so if you could list specific issues, I promise to fix them soon. As you recall you filed some bugs regarding this and I fixed them all soon after except for the one I didn't understand. BTW that bug is still waiting for your explaination. - The plugin API should instead be a convenience library around using the D-Bus API, which would make implementing other front-ends to those plugins easier. I guess it wouldn't be powerful enough for some plugins though, so maybe it should be an interface with 2 possible implementations, and the more powerful one having some extra functionality. In theory I agree but in practice this will mean double d-bus round trips in case of tracker (a backend very important for maemo uses-case) unless/until tracker guys agree to implement the MediaServer spec. Last I talked to Ivan about this, he didn't seem very enthusiastic about this. :( -- Regards Zeeshan Ali (Khattak) Sent from Nokia N900___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
3.0 readiness: I think so! The only specific relevant thing i find on ThreePointTwenty wiki is GObject introspection. Oops, I meant ThreePointZero plan wikipage. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
