<div>This is a rather large mail that I've written to Sebastian. I'm posting this on the mailing list because some people might want to know what's going on and maybe participate in the discussion. </div><div>
<br></div><div>---------------------------------</div><div><br></div>Hey Sebastian<div><br></div><div>I've got a couple of questions regarding different things. I was hoping you could answer some of them. Ideally I would have liked to catch you online but my college hours are quite absurd. :-/</div>
<div><br></div><div>Sync Library</div><div>=========</div><div><br></div><div>1. <b>Design question -</b> Generally when syncing something, it is done in 2 steps -> Identification and Merging. During the Identification all the resources that could not be identified and are NOT of type nfo:FileDataObject are created. This is done <b>during the Identification process</b>. However Artem made me realize that this might not be ideal. In his case he likes to check if the identification was successful and according merge the resources. In that case the IdentificationRequest would land up creating some Resources which would be ignored if he chooses not to merge. </div>
<div><br></div><div>One solution to this is to have some kind of placeholder uri which the IdentificationRequest maps the resources to when creating a new Resources, and the actual creation is done during the merge process. Do you approve? Or should I just let it be the way it is?</div>
<div><br></div><div>2. <b>The addition of vital properties and required properties for identification -</b> I still haven't gotten around to doing this, mainly because it would be a huge change that would break everything ( The existing syncfile format, and the internals of IR ). Do you think it is required? I didn't feel like starting it during the gsoc period as if I broke too many things I wouldn't have anything proper to submit. I'm CCing Artem.</div>
<div><br></div><div>Btw, in case you don't remember - Vital properties would be those properties without which the identification would fail. And optional would be those which are nice if they get identified but don't contribute to the actual score (How would that be useful?)</div>
<div><br></div><div>Nepomuk Syncing</div><div>==============</div><div><br></div><div>Backup kinda works ( I don't know why it doesn't work for you, some stuff with KArchive internals :-( I still have to look into it ) but I still need to do some work for Syncing to work properly. Here are a couple of things I need -</div>
<div><br></div><div><b>1. Nepomuk database identifier -</b> Syncing works pretty well when you do it once, but if you do it multiple times ( as most people would ) you have to perform the identification every time. This is not acceptable if the identification fails and the user has to do it manually. I was hoping to have some kind of identifier which could be used to uniquely identify a Nepomuk database. That way I could save the resource mappings after the initial identification are avoid re-identifying the same resources each time.</div>
<div><br></div><div><b>2. Some way to store the last sync date - </b>Initially I was going to store the date in some config file, but that wouldn't be appropriate as I need to store the last sync date to each Nepomuk database. So we probably need some kind of ontology which could help us represent this internally.</div>
<div><br></div><div><b>3. Communication Medium - </b>The Nepomuk enabled machines need to communicate with each other in order to generate the correct sync files, and transfer them to each other. How do I go about doing that? Telepathy? I was looking into Avahi, but I thought I'll just ask before I start trying something.</div>
<div><br></div><div><b>4. The GUI - </b>Any ideas or anything you can think of would be great!</div><div><br></div><div>After GSoC</div><div>=========</div><div><br></div><div>Now that gsoc is over I would ideally like to start the process of polishing the Sync Library so that it can be moved to kdelibs. That way I could start using it in all the places it should be used, namely, Strigi, Removable Media stuff and the Akonadi Feeders. I was hoping you could go through the library API, and just help out. </div>
<div><br></div><div><b>KUrls - </b>I know how you prefer KUrls over QUrls ( rightly so! ), and I think I should use KUrls everywhere in the library. It would however break the current API, which isn't a big deal since Artem and I are the only ones using it. Do you think we should go for it? Or should we just use KUrl internally? </div>
<div><br></div><div>Metadata Sharing </div><div>==============</div><div><br></div><div>Our meeting during Akademy was cut short, and there are still many things that need to be finalized. The main thing that needs to be taken care of is the new ontology for security and a couple of other things. Maybe we could set a date to discuss this?</div>
<div>----</div><div><br></div><div>I think that's about it. :) Take your time. I don't expect you to answer everything immediately.</div><div><br></div><div>- Vishesh Handa</div><div><br></div>