On Thu, Apr 24, 2008 at 4:32 AM, Peter Poeml
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'm not entirely sure that we'd need an osc-style working copy as such -- in order to integrate fully with MD, I'd probably be expecting to store the spec files and patches using the local VCS provider. At any given point it would be possible to regenerate the corresponding tarball from the VCS.
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.
Well, I can't expect really osc to maintain a 100% stable "textual" API, so parsing its output is bound to run into problems one day...
- 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.
MonoDevelop will probably offer: generating/uploading tarballs and editing spec files and project metadata, building locally, monitoring build status. I don't think we'll want much more than that. We're not aiming for a feature complete build service client, just a useful level of integration to make it easy to deploy projects to packages via the build service.
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
All of these would definitely help, yes, as long as we could rely on it having a stable (or backwards-compatible) API.
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)
I'm not sure that it's worth the effort of rewriting it in C, since a stable osc text/xml API would work fine. I don't particularly fancy writing it in C myself either. FWIW, Mono can consume Java libraries, and can execute Python, so we could write the library in Java... but let's not go there ;-)
Anyway, it would be nice to have forces joined and work together on one library, wouldn't it?
Agreed, if it's viable. -- Michael Hutchinson http://mjhutchinson.com --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org