Randy,
On Jun 25, 2012, at 1:57 PM, Randy Turner wrote:
> ...
> There was text in the minutes that the group was not going to tackle this -- is the idea not to tackle this at all? Or just that we're prioritizing our efforts and trying to complete the core model before tackling the other stuff ?
We agreed that the focus for this document will be on defining the core model for getting jobs from the Cloud Print Server to the Cloud Print Manager. We will talk about the other components in a general, abstract way (i.e. wave our hands frantically :) and document what the anticipated data elements and operations might be for those components, but we are not going to do the binding/protocol work for association or registration/service creation at this time (maybe later, if we can identify specific Cloud technologies that can be used to define the complete "system"...)
> There was also a comment from the minutes that this would be a small amount of code (10%) -- I think this may be a conservative estimate. Anyway, we're talking about completing the core "abstract" model, correct? So we're really not talking about a concrete binding or implementation, so we're not talking about code here.
The 90/10% was my comment; basically if we have concrete bindings of the CPM<->CPS interface, then all that remains is the authentication/association/registration interface. Conceptually this is a small amount of code - just what it takes to implement OAuth2 and some other cloud-specific web service interfaces - and so if we can standardize the higher-level CPM<->CPS interface we will have made serious progress that allows vendors to support multiple cloud print providers.
> Also, reaching across the abstract-to-concrete boundary, the minutes mentioned something about XMPP -- I am working on implementations of cloud services and XMPP seems like a good fit, not only because it has a very robust publish/subscribe event model, but it can map into whatever AAA we decide to use (multiple mappings exist). There's a lot of really cool extensions currently being worked on within the XMPP community (both IETF and xmpp.org). Also, XMPP could be used for registration/presence as well. It's a nice communications substrate on which many apps could be mapped.
XMPP was mentioned more for its capabilities than for specific adoption, although I do agree it may play a roll in a binding of the model we come up with.
________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20120625/dd59b7bd/attachment-0002.html>