[GSoC2012] Introduction / Impress smartphone remote control

[Michael Meeks]

Hi there,

On Tue, 2012-05-08 at 21:19 +0100, Andrzej J. R. Hunt wrote:
> just a few small (code) organisational issues -- I'm not entirely sure 
> where it's best to place the code: there are going to be 3 components:
> - The common code (thrift definition)
> - The server component
> - The android app
> 
> I thought it might be most appropriate to create a new folder in the 
> main libo directory e.g. "impressremote", which will contain the thrift 
> definitions and android app (with space to add more apps for other 
> smartphones).

	Sounds reasonable to me :-)

>   The server component I think is best kept in sd/source/ui/remotecontrol 
> for the gui part, the actual server code could be there or in 
> sd/source/core/remotecontrol.

	Having the server code in sd/source/ui/ doesn't sound horribly
out-of-place with common practise; the UNO interfaces all tend to be in
ui/ directories.

> Since thrift isn't available as a standard package on most distros (and 
> windows) would it be appropriate to add downloading and building of 
> thrift to the makefiles ? Or should I change the choice of RPC to use 
> something with simpler dependencies (thrift seems to be most suitable 
> from what I've been able to determine, although XML- or JSON-RPC 
> wouldn't really be a problem in terms of efficiency, what is more of an 
> issue is making these work bidirectionally -- another alternative is 
> scrapping RPC and implementing a custom messaging protocol, but this 
> would be less flexible for the case that someone wants to extend things 
> in the future -- in gmote they have a custom packet implemented as a 
> class for every command, with this object being serialised and then 
> sent, and deserialised at the other end -- although this wouldn't work 
> in our case since the server is in C++, and the client in an arbitrary 
> language).

	Up to you really :-) of course, adding more dependencies - particularly
if we only have a five method interface seems like quite a chunk of
work; many distros would have to package thrift, and add dependencies to
it - we'd have to make it compile cleanly on windows and mac, and then
there is the size.

	Either way, assuming the core library is less than say 100k or so
stripped, and all the above can be solved, I'm fairly sure no-one will
object.

	Then again - getting something working as a first pass, perhaps
linux-only with thrify, and iteratively improving / slimming
dependencies / growing the feature-set is usually the best strategy :-)
trying to make the perfect choice from the get-go is often rather hard.

	Anyhow - encouraged by your research :-)

	ATB,

		Michael.
-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot