Split connection methods into abstracted backends

the core of blogapi_rsd should also be changed, because this is the way clients are informed about available interfaces.

Also, I'd suggest that even if blogapi will be the required core module, it also provides some minimal stuff, like the current implemented APIs.. what do you think?

My concerns..

This is a great idea, as good as difficult to acomplish. The reason? important actor here is the client software used, that one does not understand of API separation, it may use one or other, or some of them at the same time. E.g. Zoundry raven, I'm using, uses the three of them, moveabletype for uploads, blogger to get user information and metaweblog to post the entries.

So, what I think are key points in this:

• Clients perspective: Here the clients are not users, they are software, they can't be instructed on how to do, they DO in one way or another.
• Usability: having to enable 4 modules to make use of a client software, despite some modules do this already just pumps me out of the business, hardly I'll be interested to keep tracking 4 or 5 modules for a single funcionality. But what is worse in this case is module dependency depending on client software, how may I know wich submodules should I enable to make use of a specific blogger client?.

So we split the module into several:

blogapi core module to provide what? permissions? a default settings page of what? The only one thing that looks reasonable to centralize here is the RSD generation, it is: make this module the one taking care about CLIENT software, NO MORE NO LESS. How can we deal here with permissions about functionality not being enabled? why take care of upload restrictions when there is no API enabling upload functionality? I'd say, this module that will end up doing just a few things is going to be the core required module.

submodules Providing different API and its own settings page, also each submodule should define its own services and menu handlers (therefore its own permissions). Yeah, I totally agree with this approach, but the problem here is that a site administrator needs to know wich APIs must be enabled depending on the client software in use.

However, as I said, I totally agree with the splitting, so we can just start splitting API and providing that RSD hook for the modules. Also, as pointed by jrglasgow, the manifest stuff could be included into the blogapi module to allow wlw software use this module.

so.. do we have a plan?

• 1.- split blogger 1.0 into a separate module.
• 2.- split metaweblog into a separate module.
• 3.- split moveabletype into a separate module.
• 4.- provide a hook in blogapi module to allow submodules communicate with core module.
• 5.- provide support for wlw.

So, three main issues: split the submodules (this one), the infamous hook and the wlw support..

yoink! Just one try.. if I can't I'll give even faster than I assigned to myself! lol

I may have some time for this on the weekend.

Yeah, there's some progress. It's going slow, though. I should have a patch ready to go soon though.

Also: This patch will -only- be splitting Blog API into separate modules (blog api core + backends). New functionality can be added incrementally in other issues.

Maybe I can get this wrapped up this weekend...

Maybe. I won't be available until tomorrow at the earliest, so maybe we can touch base then. My first priority is getting Blog API ready to roll, so I may stay off IRC until this patch is done, in which case, you'll get a notification when we're ready to go. Also, if you have a few spare moments over the next few days, it would be really really really really awesome if you could talk to somebody about getting Blog API on the contrib testing list as kind of a late include. Maybe it's still possible? I dunno...but it would really help with getting this ready to go, I think.

Looks like I just missed the issue and write in the wrong one.. TTestbot issue follow up at: http://drupal.org/node/689990#comment-2621680

Take your time cweagans, this one is a little bit complex.

This is tied at the hips with #728198: Update to work with Drupal 7 beta 3.

This is done in the 7.x-2.x branch.