My feeling is that it would be best to totally replace/remove glib and as many unix libraries as makes sense; mainly from performance and cross platform perspectives. I feel that continuing to try and port all these unix based libraries to run on smart devices (even though a number of these smart devices contain custom unix kernels) is way too time consuming and down the road may lead to be counter productive due to the factors I mention below. Also, all these unix libraries, as part of a smart device bundles, require a very large memory footprint.
All these smart devices (i.e. iOS, Android OS, and Blackberry) are very limited with regards to CPU speed, memory capacity, and resources in general. Scalability is very limited - on the other hand with cloud based support, HTML5/css/javascript on servers and webviews on the devices - the scalability has some greater potential. But still cpu and memory are real limiting factors. On Jul 8, 2011, at 2:35 AM, Christophe Fergeau wrote: > Hi Cliff, > > On Thu, Jul 07, 2011 at 06:12:07PM -0500, Cliff Sharp wrote: >> I would like to ask a question to extract a fairly detailed response from >> those who are most familiar with the spice architecture. >> >> What (in some detail) would be needed, as far as architecture and >> software development, to maybe start with the spice-protocol (i.e. as >> little as possible) and build a command line spice client to run on a >> platform? > > Your best bet might be to look at what spice-glib does, it's part of > spice-gtk, but it doesn't have any GUI-related dependency, so it should be > pretty light on deps, and it handles most of the low-level protocol > interactions with a spice-server. Marc-André might be able to give a more > detailed description of what this provides. > > Christophe ____ Cliff Sharp | csh...@vbridges.com
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
