On Mon, Sep 6, 2010 at 11:10 PM, Vishesh Handa <[email protected]> wrote:
> 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. > > --------------------------------- > > Hey Sebastian > > 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. :-/ > > Sync Library > ========= > > 1. *Design question -* 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 *during the Identification > process*. 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. > > 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? > > 2. *The addition of vital properties and required properties for > identification -* 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. > > 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?) > optional properties are properties that contribute to the actul score if they match, but their absence or mismatch don't decrease the actual store > Nepomuk Syncing > ============== > > 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 - > > *1. Nepomuk database identifier -* 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. > > *2. Some way to store the last sync date - *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. > > *3. Communication Medium - *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. > > *4. The GUI - *Any ideas or anything you can think of would be great! > > After GSoC > ========= > > 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. > > *KUrls - *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? > Sebastian, why do you prefer KUrl over QUrl ? > > Metadata Sharing > ============== > > 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? > ---- > > I think that's about it. :) Take your time. I don't expect you to answer > everything immediately. > > - Vishesh Handa > > -- Sincerely yours, Artem Serebriyskiy
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
