Mailinglist Archive: opensuse-buildservice (219 mails)

< Previous Next >
Re: [opensuse-buildservice] Re: gosc
  • From: "Dr. Peter Poeml" <poeml@xxxxxxx>
  • Date: Wed, 20 Feb 2008 16:59:28 +0100
  • Message-id: <20080220155928.GJ12810@xxxxxxx>
On Wed, Feb 20, 2008 at 04:36:13PM +0100, Rodrigo Moya wrote:

On Wed, 2008-02-20 at 13:24 +0100, Dr. Peter Poeml wrote:
Hi Rodrigo

On Tue, Feb 19, 2008 at 05:21:29PM +0100, Rodrigo Moya wrote:
Hi Peter

Just saw your comment on my blog about the os client. And indeed, one of
the things that slowed me down a bit last week was the interface for the
client, I am still not sure what the best thing would be.

So, can you share your ideas with me?

Also, is there a list of all the methods available in the osc.* python

Rodrigo Moya <rodrigo@xxxxxxxxxx>

Klaas, I'm adding you to Cc because we talked about KDE & osc sometimes
;-) and I'm also adding the list to Cc.

I have thought about the following ways:

simply use osc as is, calling it as external process. Adding a switch
which makes osc output stuff in XML (similar to svn --xml) would greatly
ease the job I guess. It would be a bit of work though. But doable and
definitely worthwhile for other purposes.

use a persistent osc process "through a pipe", which turns osc in some
sort of daemon. osc has some kind of preliminary batch support, I'd say.
mmarek's osc-ftp goes into a similar direction which I envisioned, when
I designed the engine. osc-ftp employs a batch mode which allows osc to
keep running, so initialization stuff is not done again and again. I
personally believe that this is the most efficient option. Again,
switching to XML mode (--xml) would come to help.

use some kind of language bindings to use osc as python library. With
KDE this seems to be possible, although I haven't really researched into
this direction, and I don't know nothing about KDE. Seems to boil down
either to an embedded Python interpreter, or to some other fancy way of
integration. (Thinking further, vim can employ an embedded Python
interpreter which would actually allow for integration too. Also, viewvc
might serve as an example, using the svn lib through Python bindings;
but it is written in Python itself.)

don't use osc and re-code everything: it's doable, and actually not so
difficult (just how I started osc), but then again it's boring... and
apart from doing HTTP requests and parsing XML replies, one needs to
deal with the iChain authentication which is a bit special if it is to
be used without getting in the way. osc stores a cookie which greatly
speeds up later requests, and renews the cookie transparently when

These are my thoughts, maybe a wiki page would be helpful to collect and
review them.

why not:

5) use osc Python API as it is now


doesn't the osc.* python API provide all needed methods to operate?

true, that's certainly possible. Some additional (osc) functionality is
built around that, through, but if you look at the length
of the code there it varies from extremely short to medium. So you'd
miss some bits at first.

And of course it would be possible to move more bits from
into, thereby making 5) even more attractive.

Would you be able to grok Python objects? Otherwise, the idea of an XML
variant seems to be most attractive to me.

"WARNING: This bug is visible to non-employees. Please be respectful!"

SUSE LINUX Products GmbH
Research & Development
< Previous Next >
Follow Ups