On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote: > Hi All, 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
