Mailinglist Archive: opensuse-buildservice (375 mails)

< Previous Next >
Re: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Mon, 28 Apr 2008 22:43:01 +0200
  • Message-id: <200804282243.01559.adrian@xxxxxxx>
On Monday 28 April 2008 17:34:12 wrote Rodrigo Moya:
On Mon, 2008-04-28 at 16:48 +0200, Adrian Schröter wrote:
On Monday 28 April 2008 16:40:57 wrote Rodrigo Moya:
On Wed, 2008-04-23 at 15:09 -0400, Michael Hutchinson wrote:
Sorry for replying without context; I only joined the mailing list
after the first few messages in this thread...

I'm particularly interested in the planning of this project and the
GNOME build service client, as I'm planning to implement similar
functionality in MonoDevelop, the Mono (C# etc) IDE. Hence if we
could share ideas, plans, designs and other information, that would
be great. It's a shame all three of us are using different runtimes,
as this means we can't share code directly :-/

yes, I think we should consider sharing the client implementation as
much as possible, so I see 2 solutions:

* write a C library and create bindings from it
* write a D-Bus daemon that can be contacted via any D-Bus bindings

for the GNOME client we were planning to use the OSC API, since we'll
be using pygtk, but since the Java and Mono clients are not able to use
it and so need to write their own client lib, I think we could use some
of the SoC student's time to work on this shared layer, couldn't we?

Reading this, I wonder why we need a standard library for the api at all.

Not that I am against it, but which functionality should go into it. I
think most should be implemented on the api.o.o side.

Pure http connect should be available in every development enviroment
these days.

yes, but if every app needs to use the HTTP API, there will be for sure
need for some extra code than the one to send and receive results, which
I'll mention below...

Can you give some examples what kind of functionality makes sense to have
in a common application library ?

authentication, error handling, basic results processing, asynchronous
calls... that is, do we want every app to deal with 1st time
authentication, for instance, or API changes in the server ?

k, but when you write a generic C library for this than you need to wrap this
one again into Python, Ruby, Qt, ... specific interfaces via another lib or
code stub. Don't you think this native code could directly use the http api ?

I personally think it is easier to handle this in native code. It is at least
easier for me to write a Qt lib directly using the http api than to wrap
around a C lib without any signal handling. While a http request is a one
liner in Qt and signal and error handling is more or less for free.

I see a point with the authentification handling though ...

We do our best to keep the API stable. But you would anyway need to adapt the
library and the native language code stub anyway if we don't ...


Adrian Schroeter
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
email: adrian@xxxxxxx

To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >