Ok; what I meant are a domain model, use cases, and a short description from fellow ranchers. For directions, one might refer to architectural information in the public domain relating to Google Cloud Printing. Secretly, I wanted to see my fellow ranchers try faulting the Google architecture. Any change from the dotted lines might well start from the initial stages. We could start by asking ourselves questions, some of which may look like the following.
1) Do you or do you not think Google's idea of routing printing data through the cloud is sub-optimal?
2) Would you consider converting everything to Google
doc format, 'cause it might entail unnecessary overheads and loss of integrity?
3) What about addressing DOS and any other relevant security
patterns?
4) How can one bring into fold printers that are not connected to the internet; however, it may, probably, be safely presumed that all users are.
4a) What about sparing printers from installing Google's proxy, which is a difficult proposition if the above is true; also, from maintenance viewpoint.
5) How could the architecture ensure using the latest printer drivers available from vendors without having to write drivers for all printer-types (for Google's OS)?
6) How can we take all printers alike, without distinguishing between legacy and cloud-print aware types?
7) If we presume that one might normally use a printer that is in the same local area, does it restrict the architecture severely? In other words, what are the tradeoffs of such assumption?
8) [This is not asked by Sun] What is the business model: how can the architecture support dynamic homeostasis?