Mailinglist Archive: opensuse-buildservice (375 mails)

< Previous Next >
Re: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?
  • From: Peter Poeml <poeml@xxxxxxx>
  • Date: Thu, 24 Apr 2008 10:32:04 +0200
  • Message-id: <20080424083204.GH21028@xxxxxxx>
On Wed, Apr 23, 2008 at 04:10:26PM -0400, Michael Hutchinson wrote:
On Wed, Apr 23, 2008 at 3:51 PM, long hong <longhong1985@xxxxxxxxx> wrote:
Do you want to use OSC? If we all use osc, then we all use the same
runtime :) Certainly using API is more straightforward. But I don't
think the two ways make too much difference.

I'd been considering using osc, but since the build service API looks
relatively straightforward, it's probably easier to do it directly
from C#. The thing that IMO might be a bit more challenging is
performing local builds...

It's not just about communication with the api -- it's also about
storing the sources locally, tracking modifications, merge handling,
cookie handling, and possibly other things.
I don't know how local sources are handled with eclipse, and how the
concept of a "working copy" looks there, but something like that
probably exists.

I would think twice, before I start to program a new client library, for
the following reasons:

- I wouldn't expect the osc library to become the source of a
performance problem when used from other languages.
Even calling 'osc' as external process should be okay, because osc
largely has network bound operation to do, which would take the same
time with a C library. Dealing with working copies is acceptable in
speed also, it seems, otherwise we might have looked for ways to make
osc faster already.

- It's really not rocket science, but even though a 20-line script is
sufficient to upload files (that's how osc started out after all), it
can take a bit of effort to implement all the other small things, and
get it right.

But I don't know which infrastructure Eclipse features. If it has local
source handling with merging and all (which I would expect), then all
that's needed is a library for the network communication, which is
indeed much more straightforward.

Some things could be done to make external use of osc (from other
languages) easier:
- osc could run as persistent process; it could batch-process commands,
saving on initialization time (it supports this already)
- since other languages wouldn't be able to use native Python objects,
we could add some kind of serialized output or XML output of the
things that osc produces


Finally, IMO:
- it would be nice if we can share working copies between the different
clients (eclipse plugin, commandline client, ...)
- it would be nice if we have one *complete* and well-tested library,
instead of a handful of libraries each supporting a subset

We could think about a rewrite in C with bindings for different
languages. (No need from the viewpoint of the osc commandline, but in
for the above reasons)

Anyway, it would be nice to have forces joined and work together on one
library, wouldn't it?

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

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