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@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org