Multi-site selective content sharing? (is this a really dumb way to do this?)

I have a client that is a nationwide restauraunt chain, with probably about 14 locations total. So far, their CMS setup is going great (drupal 4.7 is pretty damn amazing to work with.) However, there's one feature that they ABSOLUTELY insist on having that totally has me stumped though, because it's not something that drupal was really designed for, but now I need to try to hack into it. They need to have a system-wide admin be able to post content across all sites simultaneously. If that's not bad enough, they need to be able to edit any of a number of static pages and have the ability to have that update occur system-wide as well. These are pages like menus, directions, about the restauraunt, etc. and would be individualized to the local restauraunt under normal circumstances, except when corporate deemed in nessesary to make a system wide update.

Aside from reservations I have about usability in a system where local admins are getting their content overwritten by a superadmin, I have no clue what the best way to pull this off would be.

Here's what I've come up with, and it looks like it *should* work, at least for the static pages. Can anyone offer any feedback / validation / suggestions? Maybe there's a much easier way and I'm going about it all wrong? Thanks!

1. Create all the static page nodes on the various systems. (most of these will be flexinodes because of the structured content they need to store)
   
   
2. Create a module called something like "node_broadcast", that has basically 4 parts:
   • System setttings page where each system can:
     - define the sites they need to update / recieve updates from if that action is called by an admin.
     - define a "node map" of pairs of NIDs and a Broadcast ID, because you
     can't rely on all 15 "about us" pages having the same NID across systems
     
     
   • permissions created to allow people to admin the site settings and to actually carry out the broadcast operation
     
     
   • the actual broadcast operation itself. This would happen by inserting a checkbox with hook_form_alter into a node edit page, only if that node appeared in the "node map". There would be copius warnings around this checkbox about the possibility of overwriting other people's data if this box is checked. Upon submission, the node, along with it's "broadcast ID" are sent to each of the sites defined in the settings page via xmlrpc, where the node is picked up and processed by part d. (below)
     
     
   • Code to recieve and process the node to be updated via xmlrpc. An authentication process should probably happen here, and then the node is updated just as if it was edited via the nid/edit page.

Obviously, that system requires a fairly high degree of coordination between systems, which is ok because it makes it slightly more secure. It still does nothing to address the posting of new content (the only new content they'll likely have to post is events for the calendar). I'm fairly comfortable with writing modules, although I've never messed with xmlrpc. It doesn't seem too complicated though.

Is there anything obviously wrong with that plan? I'm on a bit of a deadline and would hate to go down the wrong path if it can be avoided. These will all be set up in a multisite environment using a common codebase, but storing content in seperate DBs. Maybe there's some database trickery that can avoid the need for the xmlrpc?

Thanks in advance for any insight!