for my (1) an aggregator-account isn't required -- although i understand google technically defines an aggregator as having a multi-client account.
for example, if you own the rights to the data that your clients post on your site then, you might submit their data to google-base -- using your single-user google-base account. this would be similar to how companies like ecrater work. in theory (b) (c) and (d) don't apply in this case -- depending on the depth of your customer-content security, management, and error-detection. this use-case doesn't require any google-base accounts or authentication other than your own. my (1) might use a multi-client account but only if you require distinct display-names and domains -- with all the limitations of a multi-client account; i would assume this is your (1') neither instance should require customer-brokered email. simply, you don't need users to create google-base-accounts in any aggregation scenario; just make clear that their data is public and accessible on google-base via your application. application-account-management and google-base-account-management can be thought about quite separately -- even as, at some point, they need to come together within a solution. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Base Data API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Base-data-API?hl=en -~----------~----~----~----~------~----~------~--~---
