[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Nepomuk in 4.13 and beyond
From: Ignacio Serantes <kde () aynoa ! net>
Date: 2013-12-16 9:22:32
Message-ID: CAKbQbAohKvDozWcqbAVNd9TkGJyPBAvf85N7aY0Sp9-=nhLy2w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I'm not requesting this features now but I think this must be necessary in
the future and this is the right moment to develop thinking in the future.
If not when we need this kind of features Baloo will be in a dead end like
with Nepomuk.
I think that sharing is not a particular use case and the same for having
your information accessible and any time. On the other side data encryption
is and old activities request because you want to encrypt some important
data in your mobile device. And talking about mobile devices, it will be
terrific if you can have all your Baloo information shared with all your
devices. This are features offering for several companies so I'm not
talking about a fantasy.
I'm using MPD for sharing my music, Tomahawk requires a user session and
Ampache is slow than MPD.
On Mon, Dec 16, 2013 at 1:33 AM, Andreas Hartmetz <ahartmetz@gmail.com>wrote:
> On Thursday 12 December 2013 22:23:23 Ignacio Serantes wrote:
> > On Thu, Dec 12, 2013 at 9:01 PM, Alexander Neundorf <neundorf@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 <<
>
--
Best wishes,
Ignacio
[Attachment #5 (text/html)]
<div dir="ltr">I'm not requesting this features now but I think this must be \
necessary in the future and this is the right moment to develop thinking in the \
future. If not when we need this kind of features Baloo will be in a dead end like \
with Nepomuk.<br>
<br><div>I think that sharing is not a particular use case and the same for having \
your information accessible and any time. On the other side data encryption is and \
old activities request because you want to encrypt some important data in your mobile \
device. And talking about mobile devices, it will be terrific if you can have all \
your Baloo information shared with all your devices. This are features offering for \
several companies so I'm not talking about a fantasy.<br>
<br>I'm using MPD for sharing my music, Tomahawk requires a user session and \
Ampache is slow than MPD.</div><div><br></div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 16, 2013 at 1:33 AM, \
Andreas Hartmetz <span dir="ltr"><<a href="mailto:ahartmetz@gmail.com" \
target="_blank">ahartmetz@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thursday 12 December \
2013 22:23:23 Ignacio Serantes wrote:<br> > On Thu, Dec 12, 2013 at 9:01 PM, \
Alexander Neundorf <<a \
href="mailto:neundorf@kde.org">neundorf@kde.org</a>>wrote:<br> > > On \
Thursday 12 December 2013, Ignacio Serantes wrote:<br> > > > Welcome \
Baloo,<br> > > ><br>
> > > New suggestions about development direction to avoid some problems<br>
> ><br>
> > related<br>
> ><br>
> > > to Nepomuk:<br>
> > ><br>
> > > 1) Baloo must work as a service to share information with other \
users<br> > > > and<br>
> > > minimize resources consumption. With Nepomuk a login is required and \
in<br> > > > multiuser environment this is a problem.<br>
> > > 2) Data must be stored in one repository to improve information \
sharing<br> > > > with other users in the same or other computers.<br>
> ><br>
> > Sharing information between users opens the door for security issues.<br>
> > If it should be running as a service, I'm quite sure some kind of login \
or<br> > > authentication will always be required. And you will need access<br>
> > permissions<br>
> > and manage them. Or am I missing something ?<br>
><br>
> For login I'm meaning KDE user login :). Obviously a security layer must \
be<br> > implemented and as Activities past requirement was encrypted data, one \
of<br> > the problems with Nepomuk, I'm assuming security will be implemented \
so you<br> > could encrypt your data if you like. Maybe I'm wrong :/.<br>
><br>
> > > 3) Remote installation will be a good solution in cases you have<br>
> > > several,<br>
> > > with mixed OS or old, computers in your home or your office because \
some<br> > > > users prefer sharing data over speed. With cheap cloud \
computing have an<br> > > > own server running some services will be more \
common (owncloud, mpd,<br> > > > quassel, etc...) so considering this for \
the future would be great.<br> > ><br>
> > This changes the security issues from local exploits to remote \
exploits.<br> > > Are<br>
> > you sure we want to go that way, if the plan is to make things simpler \
?<br> ><br>
> In my case yes, I can't speak for others :). I'm currently using Nepomuk \
to<br> > store music and media metadata and I would like the share this \
information<br> > with my family and my several computers and there is no plans to \
index<br> > documents.<br>
><br>
</div></div>This sounds like you need specific support for that use case.<br>
Read-write sharing requires merging changes correctly where "correctly"<br>
does not have the same meaning in all use cases. That is simply too<br>
much work when we have to make the basic things work well for now.<br>
Features like that are not like things you can bolt on the side, they<br>
must be supported in many parts of the code and make everything more<br>
complicated. What we don't need is complication.<br>
Maybe look at the Tomahawk music player or Ampache.<br>
<div class="HOEnZb"><div class="h5"><br>
>> Visit <a href="http://mail.kde.org/mailman/listinfo/kde-devel#unsub" \
target="_blank">http://mail.kde.org/mailman/listinfo/kde-devel#unsub</a> to \
unsubscribe <<<br> </div></div></blockquote></div><br><br \
clear="all"><div><br></div>-- <br>Best wishes,<div>Ignacio</div><div><br></div> \
</div>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic