On Thursday 12 December 2013 22:23:23 Ignacio Serantes wrote: > On Thu, Dec 12, 2013 at 9:01 PM, Alexander Neundorf <neund...@kde.org>wrote: > > On Thursday 12 December 2013, Ignacio Serantes wrote: > > > Welcome Baloo, > > > > > > New suggestions about development direction to avoid some problems > > > > related > > > > > to Nepomuk: > > > > > > 1) Baloo must work as a service to share information with other users > > > and > > > minimize resources consumption. With Nepomuk a login is required and in > > > multiuser environment this is a problem. > > > 2) Data must be stored in one repository to improve information sharing > > > with other users in the same or other computers. > > > > Sharing information between users opens the door for security issues. > > If it should be running as a service, I'm quite sure some kind of login or > > authentication will always be required. And you will need access > > permissions > > and manage them. Or am I missing something ? > > For login I'm meaning KDE user login :). Obviously a security layer must be > implemented and as Activities past requirement was encrypted data, one of > the problems with Nepomuk, I'm assuming security will be implemented so you > could encrypt your data if you like. Maybe I'm wrong :/. > > > > 3) Remote installation will be a good solution in cases you have > > > several, > > > with mixed OS or old, computers in your home or your office because some > > > users prefer sharing data over speed. With cheap cloud computing have an > > > own server running some services will be more common (owncloud, mpd, > > > quassel, etc...) so considering this for the future would be great. > > > > This changes the security issues from local exploits to remote exploits. > > Are > > you sure we want to go that way, if the plan is to make things simpler ? > > In my case yes, I can't speak for others :). I'm currently using Nepomuk to > store music and media metadata and I would like the share this information > with my family and my several computers and there is no plans to index > documents. > This sounds like you need specific support for that use case. Read-write sharing requires merging changes correctly where "correctly" does not have the same meaning in all use cases. That is simply too much work when we have to make the basic things work well for now. Features like that are not like things you can bolt on the side, they must be supported in many parts of the code and make everything more complicated. What we don't need is complication. Maybe look at the Tomahawk music player or Ampache.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
