[Kde-games-devel] Re: introducing synchrotron

[Aaron J. Seigo]

On Wednesday, January 5, 2011, Josef Spillner wrote:
> Am Mittwoch, 5. Januar 2011, 21:37:02 schrieb Aaron J. Seigo:
> > i wasn't aware hotstuff was still active or even an option. last time we
> > talked about these things, the hotstuff server wasn't ready for this kind
> > of thing, and tbh, perl is really not my cup of tea. not that PHP is,
> > either, but i can sling it with a bit more ease.
> 
> I see, so the issue extends to the lack of communication on my side.
> Acknowledged.
> 
> Regarding scripting languages, the first iteration of hotstuff scripts was
> even written in PHP, but its XML and web service capabilities at that time
> were poor. AFAIK they changed the DOM API around three times back then,
> whereas Perl made great buzz about SOAPLite which is now mostly dead. To
> be honest, all major scripting languages that I regularly use (including
> Python and Ruby) are still weak in this area. This is a major obstacle to
> FLOSS service development. I have a (work-related) long text document
> outlining pros and cons of all sorts of toolkits, perhaps I should turn
> this into an article :)
> 
> > if hotstuff can be made to do precisely what i need (namely: to turn a
> > bunch of directories in a git repo into a set of feeds; zip compression
> > and reading metadata from .desktop files are critical features for the
> > plasma content) and is easily installed and maintained somewhere we can
> > use, i'm happy to drop synchrotron like a hot potato.
> 
> Turning .desktop files into .meta files is not part of the scripts per se
> but there are some additional scripts to extract e.g. translations from
> .desktop files. They would need to be extended to cover your plasma needs
> indeed. The automatic zipping is also a neat feature, although I thought
> that the version control systems' web interfaces nowadays all provide this
> function to download on-demand snapshots of parts of the repo and that it
> should be used instead to avoid storage overhead. Will look into it.
> 
> > i don't need to maintain yet another project. i do need the functionality
> > it provides and it was quite easy to write it. as a result i have
> > precisely what i need in very little time.
> 
> Having yet another resource-consuming project and yet another documentation
> path split at techbase for new developers is at the centre of my worries.

actually, this speaks to the heart of my motivation which led to the approach 
i decided to take with synchrotron. in fact, let me riff a bit on this:

one of the worst things about how we manage GHNS right now is that we make 
developers care about the service side of it. imho, they shouldn't have to. 
there shouldn't be anything more to it than "push your addons in a developer-
friendly format (e.g. uncompressed) to this repository following some very 
simple file system layout conventions and then you can trust it will show up 
over there on $MAGICAL_GHNS_FEED_SERVER. then use libknewstuff. profit."

the "how" bits should be hidden magic so that those working on the server bits 
can, at will, change that. the "how" bits should be hidden magic so that the 
developer can pretend it doesn't even exist and instead just use git.kde.org 
like they alsways do and have things "just work" for them.

it's all about 100% automation of the bits that developers don't care about.

btw, did you know that amarok also has it's own little magical set up thing 
for script updates? not even ghns/ocs compatible or related. how not-aweseom 
is that?

right now on techbase what we have for documentation are "how to get things to 
work in your client side application with knewstuff". there is nothing about 
how to host your addons or how to go from "it's there in my git repository" to 
"it's there online for my users to get via GHNS".

the only possible link i could find is in the outdated:

http://techbase.kde.org/Development/Tutorials/Introduction_to_Get_Hot_New_Stuff

which links to the non-existent:

	http://www.kstuff.org/docs/

when one actually finds their way to, say:

	http://ghns.freedesktop.org/hotstuff/

there's no actual "here's the 5 second way to get your app addons online". 
it's, once again, all about users contributing stuff. as an app dev trying to 
get our addons out there, i couldn't care less about managing user 
contributions. why? because we have git for that. any other process is an 
additional process and i am suddenly resentful of it taking my time ;)

the rest of the documentationon on ghns.freedesktop.org falls into two 
categories: raw specs and client-side libraries.

so... why aren't we using these great ideas like hotstuff more, some 7 years 
after hotstuff debuts? as an application developer, my answer is dead simple:

"I don't care about the server side. Not one bit. The moment you talk about 
'server' I stop paying attention. Talk to me about how to magically get my 
code online without me learning any new tools and then I will listen."

as a community, we have never done that.

so we have all kinds of Get Hot New Stuff dialogs in KDE applications, but 
nearly zero adoption of it as a way for app devs to push their addons out. 
it's all user generated content, it's almost all on kde-look/kde-
apps/opendesktop-.org (driven by proprietary software!) and there are ~zero 
tools in use for upstream developed content. :(

with one day of thinking about it and now ~3 days of development time, i 
managed to derive a solution that can fill that gap.

yesterday i tested out the application-developer-side on a plasma developer 
who needs exactly this for his DataEngine. from the time i pointed him at the 
"sources" repo on git.kde.org to the time he had his stuff in there are ready 
to go probably less than 10 minutes had passed. that including him cloning the 
git repo, adding the files, pushing to the main repo and me explaining what he 
had to do with the providers file and where to put his files.

10 minutes.

1-2 paragraphs of "how to do it" if fully written out.

that, imho, is what we need. so .. yes, i don't care which project provides 
it, but it needs to be provided in that fashion.


btw, something you might (or might not :) find interesting about synchrotron 
is that it doesn't have an HTML interface. that is completely and utterly non-
interesting to me because my app is not a web browser. any time plasma-desktop 
opens a web browser, it's a Fail Class 1. web services? great. web browser? 
blah.

</riff>

> From a process point of view I'd say this should further be discussed at
> the GHNS mailing list at fd.o, if you're ok with me taking over features
> from you or you volunteering to replace my scripts (& hosting).

hosting is something i will work with kde sysadmin for.
i don't know what should be discussed on the GHNS because that isn't the 
interesting bit, nor is it what synchrotron does that's new!

> P.S. Lack of communication, hm, a small anecdote in lieu of a proper blog
> entry: During my remaining holidays, though not active as developer or
> researcher, I continue to be a heavy KDE user in a "one new tool per day"
> learning mode. This is something that I can recommend to everybody.

sounds like this would make a really neat one-paragraph-a-day type blog, tbh 
:)

> Currently, I'm amazed by the video editing capabilities of kdenlive. This

yeah, it's quite good. as far as i can tell, the reason it isn't more heavily 
marketed right now is that it had some stability issues. it made some big 
splashes when it started becoming quite capable and then got heavily slammed 
for its lack of stability. if stability has been addressed, then maybe it's 
time to put some effort behind raising awareness of that.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20110106/888af879/attachment.sig