+1 to eduardo. Profile view is meant to showcase user's interest/profiles to user and visitors. It's not a replica of canvas view.
Our limits are large enough to allow you to publish tweets that the user makes. I am assuming a reasonable user can do no more than 100 tweets a day. The limits are large enough to allow you to update at this rate. On Wed, May 20, 2009 at 10:03 AM, Eduardo Rocha <[email protected]>wrote: > > IMHO, the users should go to canvas view for that. > > The scenario I see with profile changes (and we probably must face it) > is that there is less room for application features on profile view, > which actually can be a good thing, because we can choose simpler > solutions and have less work :) > > On 19 maio, 15:33, gcb <[email protected]> wrote: > > what about feed readers? > > > > What if my 1mi users want fresh items everytime someone reads his > > profile? > > > > say I have an app that shows his twits. > > > > On May 19, 2:46 pm, Badaro <[email protected]> wrote: > > > > > A couple more things that probably weren't very clear from my > > > explanation: > > > > > - What defines *when* the data in the profile should be updated are > > > the user's interactions with the application in the canvas. As he adds/ > > > rates more songs and artists and changes what his favorites are, the > > > profile should be updated to reflect this. > > > > > - We probably will be using the JS API instead of REST/RPC for those > > > updates, though I imagine the limits are the same. > > > > > Filipe Badaro > > > > > On May 19, 2:21 pm, Badaro <[email protected]> wrote: > > > > > > This is the development version of the profile, which is currently > > > > using OS Templates with HttpRequest: > http://sandbox.orkut.com/Main#AppInfo.aspx?appUrl=http%3A%2F%2Fbadaro... > > > > > > The live application is here: > http://www.orkut.com.br/Main#AppInfo.aspx?appId=1086790722195 > > > > > > We have not yet uploaded the OS Templates with HttpRequest version of > > > > the profile to production, since we're still deciding if we should do > > > > this right now, or wait until we modify the application to use > > > > AppData. > > > > > > The profile intends to give the viewer a sample of the owner's > musical > > > > tastes, including some of his favorite artists and musics. It used to > > > > include a lot of extra functionality, such as allowing the viewer to > > > > preview and rate the songs displayed, but sadly this can't be done > > > > with the more restricted environment of OS Templates. > > > > > > Currently, since we're using HttpRequest, we send a random set of the > > > > owner's favorites on each visit, but after we change to AppData this > > > > would no longer be possible, so we'd probably include either the most > > > > recent changes, or the highest ranked ones. > > > > > > However, this data is bound to change often, in particular for new > > > > users, since they have no data to begin with. It's certain that for > > > > the first few uses of the application we'd be updating the AppData > > > > constantly as we get more information about the user's tastes. > > > > > > That being said, I *don't* want to use AppData for this, however if > > > > HttpRequest is removed I believe I won't have any other choice to > > > > store the profile data. > > > > > > Filipe Badaro > > > > > > On May 19, 12:20 pm, Apurv Gupta <[email protected]> wrote: > > > > > > > If you can tell us more, we can help you better. It may be entirely > true > > > > > that your app is better off using a different rendering model. > > > > > > > On Tue, May 19, 2009 at 8:29 PM, Apurv Gupta < > [email protected]> wrote: > > > > > > Hi Filipe, > > > > > > What's your use case for updating the AppData? What's your > application url? > > > > > > > > Thanks, > > > > > > -apurv > > > > > > > > On Tue, May 19, 2009 at 8:23 PM, Badaro <[email protected]> > wrote: > > > > > > > >> Can you tell us how much is that limit, and what happens when we > hit > > > > > >> it? > > > > > > > >> While this limit doesn't affect this migration process, after we > > > > > >> migrate the profile information to AppData we will need to > update it > > > > > >> constantly to keep the user profile up-to-date. > > > > > > > >> Filipe Badaro > > > > > > > >> On May 19, 6:00 am, "Shishir Birmiwal (Google)" > > > > > >> <[email protected]> wrote: > > > > > >> > Yes, there is a limit to the number of > updatePersonAppDataRequests > > > > > >> > that can be made per app per person, but given that you're > going to > > > > > >> > update for each person, you will not hit the limit. > > > > > > > >> > Cheers, > > > > > >> > Shishir > > > > > > > >> > On May 18, 7:00 pm, Badaro <[email protected]> wrote: > > > > > > > >> > > --- Situation > > > > > > > >> > > I just found out through the forum that HttpRequest will be > removed > > > > > >> > > from OS Templates, and we'll be forced to migrate all > profile data to > > > > > >> > > the user AppData. The related thread is here: > > > > > >> > http://groups.google.com/group/opensocial-orkut/browse_thread/thread/... > > > > > > > >> > > However, I have an application with several hundred thousand > users, > > > > > >> > > where part of the data needed for the profile is stored in > my servers. > > > > > >> > > Therefore, I'll need to implement an automated procedure to > migrate > > > > > >> > > this data to Orkut, and I believe my only reasonable option > is to use > > > > > >> > > the REST/RPC API to upload this data. > > > > > > > >> > > -- Question > > > > > > > >> > > Is there a limit to the number of requests that can be made > for one > > > > > >> > > application? More specifically, I'm talking about the > > > > > >> > > OpenSocialClient.newUpdatePersonAppDataRequest call. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Orkut Developer Forum" 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/opensocial-orkut?hl=en -~----------~----~----~----~------~----~------~--~---
