On Wed, Apr 23, 2008 at 04:10:26PM -0400, Michael Hutchinson wrote:
On Wed, Apr 23, 2008 at 3:51 PM, long hong
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