> Ok.. if the SQL only is too "myth specific" try this on for size... :-)
>> If the data were in an SQL database, a frontend on the service could
> EASILY export it to a file, if that's what the user/subscription/
> preference whatever decided. The point is not the format that is
> used.. since the contents of the SQL database can be output into
> almost any format imaginable at the drop of a digital hat (usually
> measured in milliseconds). Keep the format in most general,
> manageable format and distribute it as needed.
>> Senario:
No. Just export in a consistent well defined interface and let
the individual users sort out their preferences. Possibly split the
data into smaller pieces so that individual channels only get dumped
from the reference copy when their own data changes.
Provide a mysql import utility if needed.
Let the rest fend for themelves.
[deletia]
The solution needs to be scalable in terms of money and manpower.
Simpler and fewer options are better.