[ghns] Fwd: r397 - trunk/hotstuff/scripts
spillner at kde.org
Mon Dec 10 07:38:42 PST 2007
Am Montag 10 Dezember 2007 13:35:03 schrieb Frederik Gladhorn:
> it's great and encouraging to hear updates on the server side are
> progressing. There are still some points that came up for kde-edu, but will
> be similiar for the other areas of kns users.
Heh. Seems like we finally have a real case for GHNS.
At first I implemented what you asked for in private mail.
Both the Marble repo and the links to the (auto-generated) provider files can
be found here:
Further uploads to the maps directory should automatically be scanned.
Unfortunately, subdirectories are not supported yet. Those who want to help
out with such additions should join kde-services-devel :-)
If at some point we want to customise the provider file, instead of writing it
by hand I think we could introduce a special hints file for the repository.
But at least for download it does the job. For upload, it points to a WebDAV
folder, but there isn't one installed at the moment as I only had this setup
on my old notebook. One thing at a time :-)
> Different people would like to manage their data on kstuff.org, Annma for
> example asked to be able to manage the KHangman files.
> Going always through one person is quite tiresome and not very appealing to
> It would be great, if it were possible to use normal kde-svn accounts to
> access the data portion of kstuff. Do you think this would be possible?
> Having one person centrally manage all repos will now work when more apps
> are using kns.
Well, the provider and the repos are as disconnected as it gets. I can easily
enter any SVN URL and it'll check the data out from there. So you could of
course maintain the data in KDE SVN.
One benefit of my repo is that we can test the setup as hard as possible
without affecting the rest of KDE. For example, I have now installed the
pre-commit hook which checks your XML validity. We cannot do this as easily
> On the good news side:
> I implemented the marble hot new stuff, so a new map overlay can be
> downloaded. But since I do not know where exactly the providers.xml and
> similiar files can be found, I could not profit of kstuff so far.
> The same issue comes up with Kalzium, where ghns is disabled for now, but
> would be fully functional if we had it working server side.
> There another problem comes up, where Jeremy and I are not sure how to
> tackle it.
> In the Kalzium .meta files which Carsten generates with a ruby script only
> relative urls are used for the payload. This results in KNS2 not being able
> to download the files.
The meta files in the kdedata repository are used for *upload*. Therefore, the
locations must of course be given as a relative URL. It would be a security
risk to let them point to http://rogue.server/bigfilewithexploit.xxx and feed
this into the hotstuff scripts.
> As 4.0 approaches and KNS is very important to us and we do want it working
> to have a good foundation for the entire KDE4, please help us get it
> working right now ;)
> It would be great if there was a site giving a quick intro for app
> developers. Getting kns set up is easy, but then
> a) how to get data to kstuff
> b) how to find the right .xml files to make it work
Should all be solved now I hope.
So here's the current list of limitations that Hotstuff has:
* repos must be set up by hand, there's no web interface for it yet
* SVN-backed repos don't support subdirectories yet
* a lot more which will only show up after heavy testing
More information about the ghns