[ghns] KNewStuff2

[Josef Spillner]

Am Cumartesi 08 Aralık 2007 19:02:31 schrieb Frederik Gladhorn:
> I know, I'm working with Jeremy.

Yeah, but the rest of the list didn't know it yet :)
And there are 17 dozen people subscribed at the moment (including Jeremy, I 
just checked for making sure).

> Now I'll add a QStringList to the entry class to have the files handy. What
> I do not like about that is that I have a few extra tags in the registry
> xml wich does not correspond to the dtd for entries, but I don't see a
> better way to do it. Suggestions are welcome. But I think this way is ok.

We should finally deprecate the DTDs and make the XSDs authorative. They're 
much more expressive and let us more easily check the correctness, which is 
important for data uploads.

However, the specification only covers what is written over the wire. What 
applications or frameworks do is distinct from that. I suggest to come up 
with a second XSD, where we can easily derive the data structure from Entry 
and add some fields to gain a KDE-specific InstalledEntry.

Did you check with Ruphy already? He covered the local installation layout in 
another class somewhere within his Plasmagik library. Apparently the idea was 
to split along the logical "separation of concerns" to let the current 
knewstuff classes not worry about the payload's contents.

> I debugged that a while ago and made Jeremy implement it ;)
> Because you actually had a new empy list returned...

Yup, that confirms the "wasn't fully implemented yet" theory. Thanks for 
fixing this.

> Josef: You do have a test server somewhere right?

I even have a production-grade server, which has everything installed to move 
forward. Several kde-edu people got SVN accounts (to maintain the data 
without having to go through the upload cycle) but so far not a lot of 
feedback resulted from that. I'm more than happy to support you on that 
front :-)

> Would it be possible to 
> give access to that for Jeremy and me?

Yes, I'm going to send a mail to both of you with a password in the clear. 
Remind me at some point to switch the SVN setup from svn:// to https:// so we 
can switch to hashed passwords. WebSVN (trac) is already available, it's way 
better than both Apache's integrated SVN and WebSVN as used by 
websvn.kde.org.
Ping me if you don't have account data by tomorrow evening.

> We'd save quite some time if we 
> could test with it actually. I don't have time or energy to try to figure
> out how to setup the server side. Also is rating and stuff like that
> supported server wise?

Well, this is supported with DXS, and is implemented at least, although not 
well tested. We should get a basic upload/download cycle up and running 
first, afterwards we can look at the collaborative functionality.

> The next big problem that comes up is getting a real server. At the moment
> kde-edu uses the normal kde website to serve the files statically but that
> really sucks.

See above :-)
We can run test repos and production repos in parallel. We can also mirror on 
download.kde.org should throughput ever become an issue.

> This is also interesting for plasma and games and all other uses of KNS. I
> am not familiar enough with kde internals, is there a chance of getting a
> dedicated server up and running in the near future?

For the server setup it is planned to name it data.kde.org in the future. 
However, the sysadmins will likely only put that into DNS if there is a real 
need for it, i.e. if we demonstrate good usage statistics of the system.

Josef