[Nepomuk] Re: A couple of things

[Vishesh Handa]

*Hello List. Sebastian and I started talking about the current state of
backup sync, and I send him a PDF (attached) of what the current problems
are. I realize that this discussion should be more public, hence the CC. (
We are also discussing some internal stuff in the DMS )*

Hey Sebastian

On Tue, Jun 7, 2011 at 12:06 AM, Sebastian Trüg <trueg at kde.org> wrote:

> Hi Vishesh,
>
> let me start at the end:
>
> 3. ranges: having more than one range is indeed perfectly possible and
> adding support should be fairly simple. But would you be ok if we put
> that off until 4.8
>

It's just something that occurred to me, so I brought it up. I'm in no hurry
to fix it.


>
> 2. properties without a domain default to their parent property's domain
> or rdfs:Resource if there is no parent property. At least that is what I
> always assumed. But I think the former is not implemented. SO that would
> have to be fixed.
>

I forgot that all properties would have a domain of rdfs:Resource. I'll get
started on not allowing abstract properties in storeResource.


>
> 1. backupsync
> * It seems to me although it is less nice and clean than introducing
> something like DeletedResource logging the deleted resources in a
> compressed file might be the simplest solution.
>

How do we hook this up in time for 4.7? I'm hoping do re-write the backup
system this week, and have a very stable version ready for RC1. ( Yes, this
qualifies as a bug fix. )


> * Remember the backup of graphs and their metadata. Actually IMHO for
> backup simple dump and restore would be sufficient.


Of course. Now it would even be worth the effort. Dump and restore + some
amount of user identification is sufficient.


> we do not really
> need any syncing there. But if you want to keep the design then a very
> cool feature would be to allow the user to restore specific resources
> (which have been deleted or changed).
>

No. I'm going to keep syncing and backup separate. They'll both depend on
the nepomuksync library. But that could still be added.


> * If you do backups that depend on another keep in mind that
>  1. users might delete them manually (this is a minor point though
> since users should simply not do that)
>

The problem with fresh backups are that they are time consuming and there is
no way to avoid it. With incremental backups will mainly be done for
automated backups. I don't think there will be a big problem with the user
deleting the backups.


>  2. If you delete older backups you might need to merge them into the
> newer ones or design the whole thing in a way that removing one backup
> file will simply mean that this data can no longer be restored. ie. data
> older than N days is lost for real when deleted.
>

I rather not have a system like that. I'm hoping for something like this -
* User creates a backup - A - It's a fresh backup, which would be very
similar to what is being done right now.
* User creates an incremental backup - A is copied - B. And the changes
since A, are merged into B. A remains unaffected.

* I like the nxx:sameAs approach. But the practical problem with that is
> that resources on two systems could have similar URIs although they are
> completely different. Sad but true: QUUID is not even close to unique -
> for now.
>

I know the uuids are far from unique, that's why I proposed we have
something like - nepomuk:/res/some-identifier/uuid

What do you think of having some way to identify each system? And do you
have any thoughts on how the two machines which need to be synced will
communicate?
---

You haven't made any objections nor have you said - Makes sense, go ahead.
So, I'm going to assume your silence means "Yes! Vishesh, the new design is
exactly what we need, and you're awesome for figuring it out!" :-P


>
> Cheers,
> Sebastian
>
> On 06/02/2011 11:37 AM, Vishesh Handa wrote:
> > Hey Sebastian
> >
> > I've written down about the new backup-sync framework. Please could you
> > read it and give me your comments. I would like to fix backup in time
> > for 4.7.
> >
> > Apart from that, your definition of abstract properties are those which
> > do not have a range. I think we shouldn't allow properties which have a
> > domain as well. If you're okay with it, I'll make the necessary changes,
> > and implement blocking of abstract properties in storeResources.
> >
> > I was going through your ClassAndPropertyTree, and I noticed that it
> > only gives one range and domain. A property could theoretically have
> > many ranges and domain. Did you purposely avoid this? Or  is it
> > something we should take care of?
> >
> > Thanks
> > Vishesh Handa
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20110607/cad0e005/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Nepomuk-BackupSync.pdf
Type: application/pdf
Size: 118623 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/nepomuk/attachments/20110607/cad0e005/attachment-0001.pdf