Re: [opensuse-buildservice] Re: gosc
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 API?
cheers -- Rodrigo Moya
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:
1) 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.
2) 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.
3) 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.)
4) 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 needed.
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?
--
Rodrigo Moya
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
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 API?
cheers -- Rodrigo Moya
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:
1) 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.
2) 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.
3) 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.)
4) 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 needed.
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 commandline.py, 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 commandline.py into core.py, 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. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Wed, 2008-02-20 at 16:59 +0100, Dr. Peter Poeml wrote:
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 API?
cheers -- Rodrigo Moya
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:
1) 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.
2) 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.
3) 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.)
4) 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 needed.
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 commandline.py, 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 commandline.py into core.py, thereby making 5) even more attractive.
I find the osc.* API (at least for what I've used it so far, even though I'm not a Python expert) quite easy to use, so, without knowing the other options in detail (what advantages they have?), I'd vote for using the OSC python as I started doing
Would you be able to grok Python objects? Otherwise, the idea of an XML variant seems to be most attractive to me.
it's written in python, so as you clarified to me on IRC, no need for
this
--
Rodrigo Moya
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (2)
-
Dr. Peter Poeml
-
Rodrigo Moya