I am now batting nodes, complete with imagefield, between separate instances of Drupal with merriment and glee. For yes, I do have a working beta of Content distribution.
I'm about to quickly write a service to get CCK's content_fields() array from the remote, distributing site, so that the retrieving site can show a UI of possible values for a Views nodereference argument. Try it. It all makes sense once you do.
But I remember a couple of months ago, when Services was a total mystery to me. I installed it, knowing that this was what I needed to achieve this task, but I was baffled by it. What was a Service? And how come I needed a server as well? Surely a service is a kind of server? Argh! And so on.
The penny dropped a few weeks ago, when I suddenly realized that a service is really just another kind of hook_menu() item.
Consider: in hook_menu(), you define which function Drupal should call when it gets an HTTP request at a certain path, say, 'node/1'. And in hook_service(), you define which function Drupal should call when it gets a service method request, in this case via XMLRPC (which is still black magic to me, but with Services module, I don't need to know, because it Just Works). For that matter, in Drush's hook_drush_command(), you define... etc etc. They are all the same!
This has me wondering whether for Drupal 8 we should abstract this out to a general hook_callback(), where we define what function Drupal should call when it receives any kind of external input.
13 comments
Love it
May I be first to say this is an awesome idea. Abstracting calls to allow a "type" (menu, service, ahah, whatever) makes total sense to me. =)
I remember in Boston
When Dries announced that he would like to see RDF go into core for D7, various parties were wondering if perhaps services (or something similar) moving to core wouldn't be a good idea as well. While I don't consider myself knowledgeable enough on either system to really voice an opinion, I think it's worth mentioning that you're not the first to voice something similar to this, and I think you'd find a lot of support for it.
Eclipse
Why not deploy module?
http://drupal.org/project/deploy
It also uses services to push nodes to subscribers, and it manages after-publication synchronization. But wait! That's not all! It can deploy taxonomy and other site settings as well. How is the Content distribution module not just reinventing that wheel?
-Robert
Wrong way around
To be fair, when we started Content Distribution there was no Drupal 6 version of Deploy (it arrived 4 months later) and the Drupal 5 version was only a tentatively supported beta...
http://drupal.org/node/230088/release
I don't think we even noticed it, since our policy at the time was to only review modules with proper point releases. You're right, at this juncture perhaps a pooling of efforts would be sensible - in either project - whichever one has the neater feature set.
But WE WERE THERE FIRST!! =P
I looked at Deploy first, and
I looked at Deploy first, and while yes it pushes, it was all manual. You have to define plans of what you deploy, and choose to push them out.
Deploy seemed much more geared to having a staging development site where you keep sets of nodes you find useful to use on new sites. Whereas I needed something where a user just creates nodes on one site and they magically appear on others.
Yes, there is wheel duplication here, and we will need to work on that. But Deploy just wasn't in the right mindset that I needed.
To follow on: Deploy module
To follow on:
Deploy module README says it is still in alpha and should not be used in production. CD on the other hand has already been in use for some time on Greg's site.
I've just downloaded Deploy and installed it again, and it's still nothing like that I need. You need to create plans (???) and then put each node into ONE plan. This is absolutely no good for a hub-spoke system like I need, and even if Deploy was changed to allow multiple selection, it's still a laborious UI. CD initially worked with nodequeue, which for a UI is about the same, but since it's Views-based, it's not been that much work to get it to allow you to use anything as a way of flagging nodes to distribute.
The plan system just doesn't feel right -- like I say, it looks like the idea is that you keep collections of nodes and stuff on your back-end site so that when you start a fresh site you hit the ground running with initial content. Nice, but not what I needed here.
Hmm
Sounds like they're still pretty different then. Content Distribution started as another one of my little "glue" efforts to bind a few useful things together (think Michelle's Advanced Forum or my CCK Gallery) and still works like that, so it ought to be more supportable going forwards as well.
One thing does occur to me (and we're going waaaaay off topic here, but) is could a 7.x-3.x version of CD, if it ever exists, be Features-based? I suspect it could...
Yeah; and it's a shame as as
Yeah; and it's a shame as as far as I can tell, the systems for transferring stuff like comments and nodes and the like from Drupal to Drupal are going to get duplicated.
I'm already using Features on my own site to keep the Retriever content types in sync. Can't use it on the Distributor too because I have a CCK noderef on my distributed types. The views we ship as code-based, which is the same as Features would do, so we'd just be adding overhead.
It would be nice to get all the services and permissions and key settings done for you out of the box, as it's a ton of stuff to go round clicking. I don't see how that could happen though.
And: for glue it's come a long way! :)
PS
Would love to have something like comment_notify available.
Ok
Good call. Next round of updates, I'll do that. Just committed it to SVN now. (Also need to sort out CAPTCHA, since lots of people, yourself included, have been complaining about that... ;-)
Very interesting - is bi-directional distribution possible?
I have a group of websites (bookstores) which should ideally do the following:
- each site publishes book review nodes and selectively enables some of those to be "shared" to a central server
- on this central server each site admin then selects book review nodes he would like to pull to his own website
- by some act of magic the selected nodes get pushed back to the subscriber's site
As far as I understand it, the second and third steps would be nicely done with your module. But how about the first one (pushing nodes from receiving sites to the central site)? Would it be possible/necessary for all the sites to be both receivers and publishers?
Currently I am using Feeds Api to realize my workflow, but I am not really satisfied with this since the act of creating proper feeds from nodes and then parsing those feeds back into nodes is quite complicated.
sample code
"I'm about to quickly write a service to get CCK's content_fields() array from the remote, distributing site, so that the retrieving site can show a UI of possible values for a Views nodereference argument. Try it. It all makes sense once you do."
hi, could you provide some sample code to illustrate a task like this one?
thanks in advance
Do you think that your awesome module would help me...?
Hi!
First of all, amazing work! Thanks for helping the community.
Second, I'm still trying to wrap my head around all this services stuff. We've got a desktop app that we want to use to allow our users to post an image (screenshot) to their account on our site. I know Content Distribution is incredibly more advanced than the simple task I need to complete, but do you think it would work for needs?
I'm really not familiar with web services nor Drupal; so I'm so happy to have found your module, which, if nothing else, I can use as a basis to create my own that suits my needs.
Thanks for all your time and work!
Post new comment