<div><i>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 )</i></div>
<div><br>
</div>Hey Sebastian<br><br><div class="gmail_quote">On Tue, Jun 7, 2011 at 12:06 AM, Sebastian Trüg <span dir="ltr"><<a href="mailto:trueg@kde.org" target="_blank">trueg@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Vishesh,<br>
<br>
let me start at the end:<br>
<br>
3. ranges: having more than one range is indeed perfectly possible and<br>
adding support should be fairly simple. But would you be ok if we put<br>
that off until 4.8<br></blockquote><div><br></div><div>It's just something that occurred to me, so I brought it up. I'm in no hurry to fix it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. properties without a domain default to their parent property's domain<br>
or rdfs:Resource if there is no parent property. At least that is what I<br>
always assumed. But I think the former is not implemented. SO that would<br>
have to be fixed.<br></blockquote><div><br></div><div>I forgot that all properties would have a domain of rdfs:Resource. I'll get started on not allowing abstract properties in storeResource. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
1. backupsync<br>
* It seems to me although it is less nice and clean than introducing<br>
something like DeletedResource logging the deleted resources in a<br>
compressed file might be the simplest solution.<br></blockquote><div><br></div><div>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. ) </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Remember the backup of graphs and their metadata. Actually IMHO for<br>
backup simple dump and restore would be sufficient.</blockquote><div><br></div><div>Of course. Now it would even be worth the effort. Dump and restore + some amount of user identification is sufficient. </div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> we do not really<br>
need any syncing there. But if you want to keep the design then a very<br>
cool feature would be to allow the user to restore specific resources<br>
(which have been deleted or changed).<br></blockquote><div><br></div><div>No. I'm going to keep syncing and backup separate. They'll both depend on the nepomuksync library. But that could still be added.</div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* If you do backups that depend on another keep in mind that<br>
1. users might delete them manually (this is a minor point though<br>
since users should simply not do that)<br></blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. If you delete older backups you might need to merge them into the<br>
newer ones or design the whole thing in a way that removing one backup<br>
file will simply mean that this data can no longer be restored. ie. data<br>
older than N days is lost for real when deleted.<br></blockquote><div><br></div><div>I rather not have a system like that. I'm hoping for something like this -</div><div>* User creates a backup - A - It's a fresh backup, which would be very similar to what is being done right now.</div>
<div>* User creates an incremental backup - A is copied - B. And the changes since A, are merged into B. A remains unaffected.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* I like the nxx:sameAs approach. But the practical problem with that is<br>
that resources on two systems could have similar URIs although they are<br>
completely different. Sad but true: QUUID is not even close to unique -<br>
for now.<br></blockquote><div><br></div><div>I know the uuids are far from unique, that's why I proposed we have something like - nepomuk:/res/some-identifier/uuid</div><div><br></div><div>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?</div>
<div>---</div><div><br></div><div>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</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<font color="#888888">Sebastian<br>
</font><div><div></div><div><br>
On 06/02/2011 11:37 AM, Vishesh Handa wrote:<br>
> Hey Sebastian<br>
><br>
> I've written down about the new backup-sync framework. Please could you<br>
> read it and give me your comments. I would like to fix backup in time<br>
> for 4.7.<br>
><br>
> Apart from that, your definition of abstract properties are those which<br>
> do not have a range. I think we shouldn't allow properties which have a<br>
> domain as well. If you're okay with it, I'll make the necessary changes,<br>
> and implement blocking of abstract properties in storeResources.<br>
><br>
> I was going through your ClassAndPropertyTree, and I noticed that it<br>
> only gives one range and domain. A property could theoretically have<br>
> many ranges and domain. Did you purposely avoid this? Or is it<br>
> something we should take care of?<br>
><br>
> Thanks<br>
> Vishesh Handa<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><font color="#999999">Vishesh Handa</font><br>