On Tue, Dec 17, 2013 at 8:54 PM, Kevin Krammer <kram...@kde.org> wrote:
> On Tuesday, 2013-12-17, 20:09:21, Ignacio Serantes wrote: > > Hi > > > > On Tue, Dec 17, 2013 at 6:33 PM, Kevin Krammer <kram...@kde.org> wrote: > > > Hi Ignacio, > > > > > > On Tuesday, 2013-12-17, 17:55:53, Ignacio Serantes wrote: > > > > Maybe you could elaborate how a system service would facilitate this > kind > > > of > > > sharing while a session service does not. > > > > Well, because I can't do a query if service is not running unless I'm > > replicating all my data over all my computers. If I have a big database > > this would be impossible because you must wait for a long time until your > > data was synchronized. If you are running this as a service you could > > connect to that server and you don't need to synchronize this data. A big > > database in a mobile or tablet could be problematic because is common you > > have gigas in your PCs but megas in your mobile devices. > > It seems that you are describing a remote server now, which would be the > same > case independent on whether the local service would run in the user > session or > as a system service, no? > A remote server is the origin of my petitions, I like to install Baloo in a server, real or virtual because with Nepomuk it's impossible. > > > > > Obviously this was my petitions :), I'm not interested at all in > > > > Akonadi, > > > > is old computing too for people who works in only one computer, and I > > > > > > can't > > > > > > > share my Nepomuk's data with all my devices so I think a software > > > > > > developed > > > > > > > in 2013 supports 2013 software requirements. > > > > > > I think you might have some misconceptions about Akonadi but you are > > > welcome > > > to proof me wrong :) > > > > > > Probably, when Akonady has a check to disable it maybe I change my mind > > > ;). > > Which neatly proofs my point about misconceptions :) > Akonadi is started on a need basis by its clients. In order to "disable" it > you simply don't use any of its clients (which would be useless anyway > without > data). > > I feel a deja vu. Ok, I'm not interested at all in Akonadi and I don't want waste my time arguing about how good or bad it is anymore. This is about Baloo :). > > > A uniform and data type agnostic access layer sounds pretty state of > the > > > art > > > to me. > > > > Yes, but a single user one running in your user session and not as a > > service when you don't want it not. > > Not quite understanding your "but". It is exactly running in a user > session, > as a service, and not running when you don't want to. > > > With so many years of development I'm > > assuming Akonadi works well for a single user in a single user computer > > with only one session opened :). But this is not about Akonadi, is about > > Baloo :). > > True, but you brought it up for whatever reason and so I am trying to > understand that reason. Somehow it must have had some context for you, no? > > > > > For me it will be terrific when I tag, comment or rate a file in one > of > > > > > > my > > > > > > > devices and automatically this information will be available in all > my > > > > devices and if Baloo works at user level this will be impossible. > > > > > > I don't see why this would be impossible. > > > That's like saying "I'd like my email to be marked unread on all my > > > computer > > > automatically but if Akonadi wokrs at the user level this will be > > > impossible". > > > Which would be demonstratably wrong :) > > > > Yes, you are right, but this is achieved with a synchronization method. > As > > I commented in my first reply I see problems synchronizing this > information > > because different hardware in your devices. > > Seems to work quite well for PIM data (emails, contacts, calendars). > You can park a plane but this is not a proof than planes are build to be driven for a highway. I spend my first years synchronizing data before internet and I have bad memories about this years and all the problems related with synchronization. > > > Let's try an example. I have over 50.000 emails in my Akonadi database > with > > the synchronization approach if I want to search for a mail tagged as "My > > tag" and dated two years ago I will need all 50.000 emails metadata in > all > > my devices or search will fail. > > Depends on how your search is implemented and how your data is stored. > If all that email is local then accessing the data should be a problem. > Might > be more efficient when indexed but not necessarily mandatory, > If all that email is on an IMAP server, search could be delegated to it > when > the server is reachable and fall back to whatever is currently cached when > not. > > > In my case I have a tablet, two mobiles (Android and iPhone), and four > > computers (one in my job) so I need all this data synchronized in 7 > devices > > or this metadata is useless because is not reliable. The worst part is > when > > I'm in a customer office working and the only method to connect to the > > world is a client computer because 3G is not working so, in brief, my > > salvation is a server where all my mail is stored with my metadata and > > accessible from any kind device with a browser. > > And that is orthogonal to a local service for providing access to the > user's > applications how? > > As far as I can see it would only be benefitial if only one program would > cause network traffic for every single data interaction, especially in the > 3G > case. > > Sorry. English is not my language and I don't understand you. I'm talking about a server implementation advantages. If I tagged 10000 mails in my PC this is done in the server so my mobile device did not waste any byte downloading that information. > Cheers, > Kevin > -- > Kevin Krammer, KDE developer, xdg-utils developer > KDE user support, developer mentoring > > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > unsubscribe << > > And I think is time to stop our noise in the mailing list. If you like I have no problems in arguing about server approach or synchronization approach using private mail. -- Best wishes, Ignacio
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
