Posted by joachim on January 24, 2011 at 9:22pm
2 followers
Jump to:
| Project: | Web Service Clients |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I still don't get the point of resources.
I create a connection. What more do I need? The resource add form only asks me for a name and a connection -- so what am I actually adding to the system here?
Comments
#1
Ah okay, I'd broken the ahah ... ;)
But I still don't get it.
For a Drupal client that gets views, nodes, users, and taxonomy -- a reasonable set for a deployment or distribution system -- I have to add a resource for every method I want to use. It's just not practical.
#2
The idea is that resources are configured connections. Yes, you might do that in a rich client and not require resources at all. Resources are a helper for clients where that may not be practical and what you need is some specific data stream rather than a configurable connection to a source. I'm open to a rethink for 2.0 branch but I think we need to cater to Feeds and Views clients.
#3
They definitely need to be optional for a 2.0 branch.
Not sure how best to work that into the code -- so far I've chucked in a second calling function that just takes connection, method, params.
#4
Also, I find the pattern for using resources confusing.
Connection classes have methods like:
static public function call($connection, $resource) {
Since resources are above connections in the stack, why does a connection need to know about them?
Would it not make more sense to use a resource by saying $my_resource->doStuff() and let the resource class figure out which connection it belongs to and what it's meant to do?
#5
It was necessary to destroy the village in order to save it: #1114314: mothball Resources system.
Now that's done, and once a 2.0 release is out of the door, I plan on coming back here doing some pondering.
One thing to say straight away is that in several of my modules that use client connections -- content_push, various applications of Transport module -- I end up having the same admin UI that just goes 'pick a connection for this functionality'.
It seems to me that this was one of the purposes of resources, and generalizing this UI (for saying which connection is to be used for a particular function) seems to me to be at least a starting point for resources 2.0.
The feeds and views stuff I am really less sure of. I think for those it would be good to start off by stating a use case.
#6
So here's a plan for resources. The use case is a module that provides remote blocks from other Drupal sites -- I've already coded this as a one-off for a project using the views service in Services, but this could be made generic and for any kind of block.
A resource type thus has:
- a list of potential connection types it can work with. Eg, the remote block resource can only work with a Drupal connection)
- a UI for its specific type. The remote block UI would have settings for module and delta, or in a perfect world, a list of blocks defined on the remote site to choose from.
For a particular resource we have:
- storage in the DB or in code via CTools exportables
- same as with connections, we have to lump type-specific data into a fat config array
- the machine name of the connection it belongs to
- its own machine name
- human label
The resource module takes care of interfacing with the rest of Drupal. So for example, a remote block resource declares its block with hook_blook().
On the other side of things, the resource object knows how to gets its data from the connection. In the remote blocks case, it does: $block_content = clients_connection_call($connection_name, 'block.get', $module, $delta);
The connection UI should show all resources set on that connection. That could become a pretty long list (one resource for each remote block!) so some sorting would be good there.
There should be caching of remote results, though I'm not sure whether this should happen at the connection or the resource level. On the one hand, it makes sense for a whole connection to have a cache lifetime setting, and different resources may use the same piece of data. On the other, with the remote blocks example alone, an admin would know whether some blocks should be refreshed, say, hourly, while others can be left for longer.
Possibly a hybrid approach, where the connection stores the data in a way that's keyed by method name and parameters, and resources can choose when they invalidate the cache.
Final question is whether it's worth developing this on 6, or updating Clients to 7 first.