Hi all, The few days off gave me some (more) time to think :) And here're the results (some pasted from the forums, others rewritten from IRC):
I thought a bit about personalization and mobility of elisa's preferences... I'm not sure if there's any point in making anything more than what's possible now with the use of user accounts... The personalization part's obvious - just run elisa from a certain account - a GDM login screen with a selection of user accounts would be nice - it could even use simple numeric passwords to be used with a remote. Since any proper use of elisa requires some central storage (the backend), be it local or networked, having the accounts on a shared drive seems good enough. On the other hand... there are some usecases that wouldn't work this way... a) if elisa would handle seen/not-seen properties of movies/episodes, I'd like it to be possible to set several people that are the 'audience' at the moment... b) problems when the backend is unavailable On the third hand... a) this kind of info could easily be handled server(backend)-side (as some metadata or tags) b) there could easily be a 'backup' account on the frontends, though. And anyway having the backend unavailable in such setups means bigger problems than not being able to run elisa... I'd like the user preferences file to be divided (or allow includes (or does it, already?)). That way I could easily share setups between my HTPC and my laptop, even if I'd like to use a different set of frontends on them. Also that would ease the mobility part of the preferences - as the user file would not contain machine-specific configs, only user-specific. Has anyone any spare hands? I'm one short already... The new REST architecture gives us the ability to simply put a uri like http://jamendo.com into elisa and that's it, as far as configuration goes - the UI gets populated with proper resources. The problem is that now you have to set the uri's label (model.text) and icon (model.theme_icon / model.fallback_icon) to be displayed nicely. Say I have some favorite bands I want listed somewhere in my menu - I'd have to learn and provide all the proper data for the uris to show up nice. My idea is that the ResourceProvider responsible for a particular uri would be called with the uri and return a complete model with all the relevant parts set - just as if it was retrieved in a ListModel from the ResourceProvider in the first place. Of course if some data is provided for the uri in the configuration (like the label, for example) it should not be overwritten. Is that more understandable now? And a question - all's fine when we want to have providers for things like flickr, picasaweb, youtube etc., we can then have proper http:// regexes and all's ok. But the problem arises when we want to have provider for things like http://gallery.menalto.com, http://vcddb.konni.com that are decentralized (for lack of better word) are schemes like gallery://, vcddb:// to be used in these cases? Or maybe gallery+http://, vcddb+https:// etc? That seems to be the common way, lately. -- Michal Sawicz <[EMAIL PROTECTED]>
signature.asc
Description: To jest część wiadomości podpisana cyfrowo
smime.p7s
Description: S/MIME cryptographic signature
