[kde-edu]: update kvtml files via internet

[Jeremy]

On Thursday 24 January 2008 08:44:56 Michael Hofer wrote:
> Am Donnerstag, 24. Januar 2008 schrieb Falk Dechent:
> > But the problem is with changes in the kvtml file like spelling errors
> > AND keeping the current grade of the lesson.
>
> [...]
>
> > well I know that diff and merge are really powerfull but this won't do,
>
> For passing on vocabulary files to somebody else (which I think is a very
> important operation), it seems more logical to me, to keep vocabulary data
> and grades separated in the first place. So one kvtml file containing all
> the vocabulary data and another xml file (which is private to each user)
> which contains only the grades.

Yes!

I tried to convince Frederik to go this way last year when we were fleshing 
out the kvtml 2 format, but we couldn't think of an easy way to link the 
grades to the entries.  An entry's id is unique, but it can change when an 
entry is removed from the middle of the list, so that complicates things a 
bit.

> As a side effect it would be easier for other applicatons (like my mobile
> vocabulary trainer MobVoc) to write back grade information (wouldn't have
> to write the whole vocabulary data, but only the grades).

And also prevents having to copy the whole vocab file from the system folder 
to the user folder when you save after practicing in the first place.

> > my Idea: extend the kvtml format with:
> > html link to latest version
> > uniqe identifier for each entry
>
> AFAIK there is already a unique identifier for each entry (the id
> attribute), isn't it? This could be used to connect the grades to the
> entries. If there was also a version attribute (just an incrementing
> number) saved in both files, the applications would easily know if the
> grades are still valid after replacing the kvtml file with a newer version.
> Updating a kvtml file would be as simple as replacing the file in the file
> system (no special merge operation needed).
>
> With the version saved within the entries, it would also be easier to
> extend this to do a real merge (that keeps user changes).
> - if the id of the new file is higher, use the entry from the new file
> - if it is the same ask the user
> - if it is lower, keep the users version
>
> A link to the "official version" inside the kvtml file could be a good idea
> (for simple replacing as well as for a real merge). If the "real merge" was
> implemented, this could also be easily extended to enable bi-directional
> synchronization with the official version (write back your changes to the
> official version....).

that may or may not be ideal... There's not always an "official version" of a 
kvtml file.  I'd like to see khotnewstuff used for this, but I'm a bit biased 
probably.

Jeremy

P.S. Michael, and anyone else that would like to discuss this feel free to 
come by #kde-edu on freenode.org anytime :)

>
> servus,
> Michael
> _______________________________________________
> kde-edu mailing list
> kde-edu at mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu