On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote: > On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote: > > Hi All, >
Ok, so take three: (1) spice-protocol - remains unchanged. specifically, despite the name, will not contain the .proto nor the python codegen bits nor the generated files. (2) spice-common (repository spice/common) - new repository, contains: spice*.proto spice_codegen.py and friends (python_modules subdir) produces a proper shared library, used by spice-server, spice-client, spice-gtk, named libspice-common.so.0, containing marshalling and rendering code (including any decoder/encoder) plus anything else currently in common (like ssl-verify). (3) spice-client - breakoff client subdir from current spice (maybe rename+remove-the-rest to keep history) (4) spice-server - rename current spice repo (just to keep history) (5) spice-gtk - remains, just move it to freedesktop now that we want to keep it. (6) spice-all - convenience repository that has the rest as submodules and has a helpful makefile to build them all. The rest of the repos will need to be updated. Concrete steps would be: (1) create spice/spice-common, spice/spice-server, spice/spice-client, spice/spice-gtk repositories (btw - any comments on the spice- prefix?) (2) get spice-common to build, the rest to use (3) remove the "spice/spice" repository (4) make spice-all Comments? > Ok, take two with Gerd's and Hans's and Uri's comments. > > (1) spice-protocol - keep it, move code generation stuff here > (spice_codegen.py, python_modules, spice*.proto), and have the dist tarball > contain the cpp and c files resulting from running it. > > (2) spice-server - new repo from spice/server, will submodule common. will > keep requiring spice-protocol as a separate entity, and will reference the c > files therein (does this make any sense, carrying c files as installed files? > I can't think of any other outcome of moving the codegen to spice-protocol) > > (3) spice-client - this will be the spice-gtk repo (or is anyone in favor of > keeping spice-gtk name?), and it will submodule common too. > > (4) common - submodule. easier to do cross changes with spice-server and > spice-client, > dist tarballs package it (for spice-client, spice-server). > > And the rest don't require any changes: > > Rely just on spice-protocol, as before: > linux/vdagent > windows/vdagent > spice-xpi > spice-x > windows driver > linux driver > And these rely on spice-server, same as before > qemu > xspice > > > > > We currently have the following repositories: > > spice-protocol > > spice > > spice-gtk > > > > spice-protocol contains the following parts: > > qxl_dev.h - required by qemu and drivers > > controller.h - required by spice client and xpi/active-x > > the rest - protocol definitions for server and client > > > > spice is composed of > > codegen - generation of marshallers, demarshallers, and defines that go > > into spice-protocol. > > server - server implementation > > client - old client implementation > > common - shared by server and client, further subdivided to: > > glz/lz/quic encoders and decoders > > cache implementation > > canvas rendering implementation > > used by the server, old client and new client. > > > > Inefficiencies with the current repositories: > > 1. updates to the protocol need to go to spice/spice.proto, run the > > codegen, > > and put the results to spice-protocol > > 2. common exists in both spice and spice-gtk. since it hasn't been > > touched in > > a while it isn't a real problem, but still the code duplication is bad > > and > > in the future (3d canvas) it will be modified. > > > > Suggested changes: > > spice - merge spice-protocol into it > > spice-protocol - kill it > > common - extract to a separate library, it's own configure, pkg-config, > > name it spice-render, > > and have spice-gtk and spice (server and old client) rely on it. > > spice-gtk - keep it as is. easier to develop with a separate configure > > since it doesn't contain > > all the requirement checks for the server. > > > > Suggestion is Marc-Andre's but he didn't think it was important enough to > > discuss, I take > > responsibility for the time wasted as a result of this email. > > > > Alon > > _______________________________________________ > > Spice-devel mailing list > > Spice-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/spice-devel > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
