[kde-edu]: update kvtml files via internet

[Frederik Gladhorn]

Hi you all,

I like the idea and maybe even possible, though not easy and also probably not 
much fun. I updated the dtd a little but there are still some minor things to 
clarify. When discussing how the new kvtml format should look like a year 
ago, not a single response came, so we did our best. Thanks to Peter and 
Jeremy the new format is pretty usable now.

From a practical point of view, one could create checksums for the entries 
somehow and only use the grades if the checksum is the same.
Fixed entry ids might be another (easier but less robust) approach.

So if someone is actually good in XML and friends, speak up!

Also I don't have time at the moment. The 4.1 Version of Parley is still 
pretty shaky, so I could use some help getting it into shape. (Yes, one or 
two features are sneaking into it...)
(Just to whine a bit...) Step up, I still have some things on my list that can 
be done by non-programmers.
One thing that would be great, would be to write about Parley on Freshmeat, 
improve the description on kde-apps.org (mail me a better text), get an 
article about it somewhere (for example http://debaday.debian.net/).
Or just improve the horrible handbook and send me the changes (if then people 
write just a little section...). Update some section of the web page. Do 
crazy things. Write Java apps to learn mobile ;)

Merge btw was used to unite files in old versions but no one had the curage to 
touch that code again (should be much easier now in comparison to the old 
code...)

Greetings
Frederik

El Thursday 24 January 2008, Jeremy escribió:
> 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
>
> _______________________________________________
> kde-edu mailing list
> kde-edu at mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu



-- 
Parley - The Vocabulary Trainer
http://edu.kde.org/parley/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-edu/attachments/20080124/ea4f8748/attachment.pgp