conversion to a Clients plugin

> - Its UI needs fixing.
> - It needs to be a model we can work with. Currently you have to enable Services on each connection, which just strikes me as a fiddly step when the services already have both key access and regular Drupal permissions.

These are reasonably trivial and on the todo list but I'm not 100% on the timeline. I'd be more comfortable stabilising the module further before refactoring the UI.

> - A resource needs to have access to more than one remote service.

A resource is a configured service by definition. You can't really just multi-select them as they can be returning entirely different kinds of data and each service will have different input parameters. I think this would be addressed in the client which would select a resource for each function it requires (probably filtering on service type). If you want to be able to capture whole configurations, Feeds provides an example of bundling various plugins into an importer - maybe your client could do something like this. Import/export of configurations for connections and resources is definitely something I've envisaged in the clients module.

The screenshot from CD corresponds to a connection in Clients (minus the reset and persistent login which could be feature requests). First stab at clients had just this and the client then handled all the method calls itself as you describe. However, this turned out to be unworkable when making a views or feeds client due to the quite basic form injection available - so this was pushed back into the core module of Clients and called resources, which was actually a cleaner approach overall and creates thinner, more maintainable clients.

A CD client could certainly address the connection directly but I think we should set some fixed API calls for connections in this case (I think this would be basically setting the existing ones in stone but we should both review that first).

I'm also wondering how the configuration of this client will work as it sounds like it will have hardcoded dependencies on certain services being available. I thought it would be better to push this back into resources and your client could then be simpler, just assigning the resources and calling them through their API. That's why I was suggesting scriptable bundles of resource configs which would allow your client to provide default setups. But YMMV on that part and there is work needed on making Clients config scriptable.

Maybe you could make a v1 which accesses connections directly as it's closer to your existing implementation and we have the basic parts in place, and revisit moving some of it out to resources later? I think the reset could be handled in your client (or using the http_reset module)? That would just leave the persistent login which sounds like it might be something Clients should be able to do.

The blowfish encryption is just so that you don't have to store a cleartext p/w and is a bit safer with stuff like pulling dbs from live > dev. A related thing that needs developing further (though shouldn't be a problem for current implementation of CD) is that clients_drupal currently expects login and key auth on the server - we'd also want to support no auth/oauth etc.

This would be extremely useful.

Something like #827524: Add support for using the UUID module to determine whether a node is inserted or updated would also be useful in this case.
Although if the client was also stored in the content_retriever table that would also make it unique.

Also, being able to pull nodes from multiple views of a client would be useful in addition to multiple clients.
See - #827610: Allow retrieving nodes from multiple views

I'm not sure about the clients module at this point.

It is quite possible a client (or myself for them) will be implementing a setup that will require this, so patches will come at that point.
It'll be good to have someone reviewing them, thanks.

Having reread my last comment I'd say nothing has changed - you can just ignore resources and access connections directly, doing all your resource configuration in your client. Resources are meant as a convenience for clients not a hindrance. Since you'd be making the first client implementation to do that, we should freeze the connections API. Also need to keep an eye on http://drupal.org/node/721640

However, I think abstracting resource configuration to the centre isn't a bad design for Clients in principle, and simplifies client implementations hugely. If the current Clients way of configuring resources is a usability faff compared to how you'd be doing it in a CD client (quite believable), I'd be very up for improving it on the Clients side. As I said, I'd also like to see Clients configs exportable/importable and allow client implementations to install presets.

I'm in the same boat regarding dev, have moved on to something else as Clients does what it needs to do for the project it was written for. But I've opened up some discussion regarding co-maintainership for the purpose of taking it forward - suspect it's a bit encompassing for one person to do well in any case. Let me know if you want to be part of that.

Is this particular development path dead then?

We're interested in developing additional features for Content Distribution, including potentially UUID integration and multiple Receivers per site, but not if its going to be rearchitected.

I am closing this issue, as Drupal 6 is now not supported.