Hm, interesting. Seems to me a) through d) are problems either way, but let me re-state your definitions to see if we're on the same page: (1') Using an aggregator account (single token) to write to customers gb feed (no token/pswd management) (2') Using the customer's account/token to write to gb. (Manage token per client)
I was thinking that (2) does not require the brokered (email) agreement between Google and ourselves and our customer as per (1), but I guess you would say Google is still the intermediary in the auth. token exchanges So they may in fact be identical for all practical purposes? In scenario (2') I'm assuming the data is written to the client's feed per force. (i.e. I don't need to jam clientid into the batch(url,feed) call.) On Sep 16, 3:20 pm, Celebird <[EMAIL PROTECTED]> wrote: > as you imply, there are probably at least two > aggregation account-management architectures. > > (1) submit customer data under your account; > (2) customer's submit their data through your application. > > trade-offs probably include: > (a) requiring (legal) permission to access customer data; > (b) risking users creating bad content; > (c) requiring customers to create a google-base account and > then authorize your application to submit data on their behalf; > (d) risking users denying you future access. > > the cost/benefit is rather difficult to assess > without knowing more about what you want > the user-behavior and end-result to look like. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
