Thanks for your response Dan! I love thought provoking ideas :) Right now I'm looking at three app data objects: [1] userPref - user preferences. It could be a skin selection for the app UI, etc [2] mostRecentGifts - the N most recent gifts as you described below [3] allGifts - I'm using a flash app so this could also be zlib compressed + base64 encoded to allow it to store more data within the 10KB quote. The most recent lists would still be a raw JSON string for fast loading (and zlib compressing a short string would be pointless).
I may then do a periodic store of [1] + [3] to my own database for reporting (what's popular, usage stats etc). By breaking it in to two lists you can also do things like grab the allGifts list for the top M friends (let's say the top 5 friends + possibly the owner), then grab the shorter mostRecentGifts for M+1 to some kind of limit (top friends 6 through 100). It sort of depends on the app, the importance of showing all of the owners gifts (not wanting to miss older gifts between the viewer and owner that are not in the recent list), what N is, etc. Anyway, lots of idea. I appreciate your response! Thanks Dave On Feb 22, 4:06 pm, "Dan (Google Employee)" <[EMAIL PROTECTED]> wrote: > Hi Dave, > > I have a few quick comments to answer your questions. > > First, the tutorial will likely be amended, because as it says at the > end, there are a lot of things it doesn't cover. It does try to point > out some of the gotchas, but this isn't one of them, and I agree it > should be added. Your experience with how beginning developers use > tutorials, and mine are directly in sync, so it's likely that those > developers will encounter this shortcoming. > > Second, here's my suggestion for scaling the app to hundreds of users, > at least in terms of optimization for displaying recent gifts: > > Instead of loading all of the gift data in one object (givenGifts[]), > have two objects. The first of the two objects keeps the historical > record of all gifts, and the second object (a queue of gifts of N > length) keeps the N most recent gifts. When fetching data to display, > pull down only recentGifts and use that to display the recent gifts > (given or received). > > When sending a gift, push the newly given gift on the top of the queue > and drop the last item. Save this information to the persistent > storage and update any relevant UI elements. In the background, create > a second request that fetches the entire list of given gifts and > append this entry to the list, and save it. > > The advantages here are that you get only N entries (for OWNER given > gifts) and N * friends entries (for friend given gifts) when you load > the gadget. On an update you still incur the penalty of fetching the > entire list (and have to do a little more work to update the second > list). But, if this app is sitting in someone's profile page and > showing their recent gifts, the N entry fetch is far preferable to > loading the entire list, and worth paying the small penalty. > > I'd say that if this doesn't perform well enough, your app is popular > enough that it probably needs it's own storage mechanism, like a > database updated via makeRequest. I can't promise that a tutorial > along those lines is in the works, but I think it would probably be > helpful. > > I hope this answers your questions. > > Best, > Dan > > On Feb 20, 7:24 pm, davew <[EMAIL PROTECTED]> wrote: > > > Hi Jelena, > > > You can request more than 20 friends. But I think the spec says it is > > up to the container whether or not it returns the number you request. > > And if the container doesn't return all of them then the app would > > have to make more requests? Google, can you confirm? > > > I also think the 10KB is per user, per app and there is a request to > > increase it. 10K is actually quite a lot of data and you can store > > nice data objects with ease using string encoded JSON. > > > Anyway I guess my points are: > > > [1] I think the 0.7 gifts tutorial should be updated to include the > > drawbacks of such a code design. Mention the limitations of requesting > > data for all friends, and what happens when a user has 500+ friends, > > etc. I've done tutorials for an API before and most developers will > > simply copy the tutorial line for line without realizing what happens > > when it goes above a certain number of users. > > > [2] Also it's seriously cool that google provides data persistence for > > applications *for free*. Storing data in your own database is, of > > course the ideal, but using google's data persistence you have free > > storage + they have the servers that can handle 10 million+ users with > > ease. > > > Anyway, would any from google like to comment on scaling a gifts / > > poke like application based on the 0.7 tutorial? Obviously storing > > multiple gifts / pokes per user is easy using stringed JSON. But I'm > > still not sure about the whole having to fetch data for all users just > > to work out recent gifts.. > > > Thanks > > > Dave > > > Jelena Kolokotronis wrote: > > > Yes, 20 default, but you can request more (arbitrary max?) number of > > > friends through optional parameters. > > > > In any case, I think that the whole app data stuff isn't really meant to > > > be used with huge amounts of data and can't really provide flexibility > > > and scalability as you make your app more complex. I'd use it for some > > > settings or temporal storage/cache. It's limit of 10K (if I remember > > > correctly?) is another reason. > > > > I guess in the end you will want some sort of backend server (sql?) for > > > the app data and all persistence. Again, depending on the depth of the > > > app. > > > > Just my thoughts > > > > Jelena > > > > davew wrote: > > > > It's great that google provides a nice 0.7 tutorial. However, doesn't > > > > it have serious scaling issues? I completely understand why you're > > > > storing sent / given gifts in the viewers app data - it's the only > > > > safe way of currently doing persistent data. But when a user may have > > > > 500+ friends is this a good way of going about doing a gifting > > > > application? It looks like the friend requests / responses return the > > > > 20 top friends (at least it's inferred from the docs). But if the > > > > application wants to show all of the most recent gifts, the app has no > > > > choice but to request the friend + friend app data for every single > > > > friend, possible several hundred, or 1000+ friends. Let's say you have > > > > 1000 friends and you're storing the most recent 5 given gifts for each > > > > friend in a JSON format. That's quite a lot of data you have to load, > > > > just to work out the most recent 10 gifts that you might want to show > > > > to a user... > > > > > Anyone have any thoughts on this? > > > > > Thanks > > > > > Dave --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Orkut Developer Forum" group. To post to this group, send email to opensocial-orkut@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
