This is the list of all networked classes and where they're used in the code. It is meant as a kind of check-list for finishing the xmlrpc => REST conversion.
This list is largely a result of looking at the namespaces in lib/puppet/network/handler/, and then grepping for the associated clients from the code.
ca
This is the certificate authority. The current code accepts a certificate request and returns a signed certificate, so following the REST model we'd need to serve those classes separately. The certificates also require, at least, a private key, which needs to be stored separately.
You can look in lib/puppet/sslcertificates/support.rb for a good picture of what needs to be managed. This module contains code for loading, generating, and storing all of the certificate-related objects.
Note that a ca cert is a normal cert but with a different path; we don't have a good way to handle this right now, so it might just be a one-off.
filebucket
This namespace is used for backing files up; you store a string, and can later retrieve the string by its checksum.
The server-side pieces of this are already done; I renamed it to checksum, since it's essentially a file storage tool that uses the file's checksum as the key.
This is used by the Filebucket type in type/pfilebucket.rb, which is itself used by type/pfile.rb when backing up files.
fileserver
This is the big bear of them all. This is used for retrieving file metadata and content from a remote or local system, and it can be used recursively.
Once again, I think I've done the server-side pieces, but the client stuff is still to go, and I expect this is the most complicated of the namespaces to port. All of the client-side code is in type/pfile.rb or in type/pfile/source.rb. Look in the sourcerecurse method in type/pfile.rb, or the retrieve method in type/pfile/source.rb.
See the lib/puppet/file_serving/ directory for how I've set up the new server-side code. It's split into three classes: Content, Metadata, and Filesets. Filesets are only used for recursion. There are also Mounts, which are used to provide specific subdirectories to clients.
I expect I will have to do this work, but I'd be overjoyed to find someone else will.
master
This is the other complicated namespace, but it's complicated because of the client code rather than the namespace itself. Its job is to retrieve and apply the remote configuration.
Basically, the network/client/master.rb file has a ton of application logic in it, and most of that logic needs to be moved into a stand-alone class. The actual configuration retrieval will be done via the 'catalog' interface, which is pretty straightforward, but the rest of the code needs to go somewhere.
This is also the class that gets wrapped in the event-loop, and the runner namespace uses an instance of this class, too.
report
This namespace is used to upload transaction reports to the server. It's called from the send_report method within Puppet::Transaction.
The server side has multiple report processors, each of which is a module that gets included in a duplicate of the report. This stuff is already ported over to REST on the server side, the client just needs to be updated.
resource
This namespace provides the ability to query resources or to upload resources which then get applied. No one is actually using this interface for anything, but I think it's a critical functionality going forward, because it allows network-wide resource queries and also allows pushing resources to clients.
There is currently no client-side code using this, so only the server-side parts need to be ported.
runner
This is a remote trigger, which initiates a client run.
This would need to find or instantiate an instance of the class that knows how to download and apply the configuration, and it has some arguments that it needs to be able to pass on to that class (e.g., tags, whether to ignore schedules, and hopefully more in the future).
Only the puppetrun executable uses this as a client.
status
This is basically a fake namespace; I use it some in testing, but it should probably either be removed or changed to actually provide some useful status information. Nothing other than tests use it as a client.
