I kind of see what you are saying after viewing the Google IO talk. To clarify, my app is more about the aggregate of books read, using friends as a filter. Stephen Johnsons reply suggesting a huge table is kind of like a materialised view I suppose, but Im not sure that I need that, and the fan-out problems that it seems to create.
For instance, if Stephen Fry, befriended by millions, adds a book to his list, for my app, I *dont* need to push that information at millions of users within seconds. They only need to know about that book when they ask the question "what are all the books my friends have ever read?" ...and the number of friends a user wants to follow is likely to be much less than the number of of users who could be following a particular user. For example. I could cap the number of users a person can have in their friends list to 500. That is a useful number, not likely to restrict anyone much. So Stephen Fry might only have 500 friends himself, but he might BE the friend of millions. But my request depends on the 500 friends and the books they have read. I dont want it to depend on the millions if it doesnt have to. Stephen Fry doesnt care about all the books read by the millions of schmucks following him, he just cares about the all the books of the 500 he is following. but then my problem comes when I have 1000 users asking simultaneously : "what is the list of all books read by my 500 friends" (who average 50 books read each). However, the other thing I suppose is that there are only so many Stephen Frys in the world. Most users will be schmucks that nobody wants to follow, so when they read a book, its a tiny blip to update the 'materialized view' table. On Jul 8, 4:55 pm, Martin Webb <spydre...@yahoo.co.uk> wrote: > Yes thats it - perhaps the word stream is not the most appropriate. > > If i read a book which is say horror - in your app that can auto subscribe me > to > books that are of the horror type. which again is just following a book type. > But the streams and subscribers principle works for lots of solutions. email > or > chat, and activity logs. comments. just use your imagination. > > Assuming that perhaps your plan is the have activities and share them with > followers - which might just be what books they are reading all you do is > send a > message to a stream. > "hello world" to " user/martin/stream/public_activities - if public facing > users > are subscribed they will get the message. Or "Hello World" mail/martin/inbox". > Of course in a real world mail system you would put a copy in the senders sent > and a copy in the recipients inbox - but thats easy. > [mail/steven/sent,mail/martin/inbox] > > # just a simple message class with subscribers - this can be far more > imaginative > class message(db.Model): > sender = db.StringProperty() > body = db.TextProperty() > > class message_index(db.Model): > receivers = db.StringListProperty() #streams > > def put(stream): #puts a stream list in a message receivers list > #should start a worker to append the past list > return > def move(from_stream,to_stream): #replaces a stream with a new stream > inbox----.spam > #should start a worker > return > def delete_stream(stream): #removes a stream - this is useful for > unsubscribe > #should start a worker > return > > As simple as this approach is it just about covers - activity walls, > email,comments and so on - one concept is lets say I want to flash messages to > my users "your are now following martin". I just have my Ajax or static page > "listen" to 'user/martin/flash' and send info messages to 'user/martin/flash' > so > when someone unsubscribes, a message is flashed to inform them the request was > completed. Of course you would need to add some security measures to the > stream > class and a mechanism to remove messages - i.e spam folders would clear say > every 7 days, flashed messages once read clear instantly, in-box messages may > live forever. Of if you want to save memory and have millions of users have a > "mail/martin/saved" stream and then add a save message button to emails (all > that does is use the message.move(...) method and then set in-box to keep > messages for say 90 days and the save box to be 'permanent' As you can see the > stream method now has some very useful functionality from just a small amount > of > api. > > Well that's how i am thinking, maybe this can work for you. > > Regards > > Martin Webb > The information contained in this email is confidential and may contain > proprietary information. It is meant solely for the intended recipient. Access > to this email by anyone else is unauthorised. If you are not the intended > recipient, any disclosure, copying, distribution or any action taken or > omitted > in reliance on this, is prohibited and may be unlawful. No liability or > responsibility is accepted if information or data is, for whatever reason > corrupted or does not reach its intended recipient. No warranty is given that > this email is free of viruses. The views expressed in this email are, unless > otherwise stated, those of the author > > ________________________________ > From: stefoid <stevenmath...@yahoo.com> > To: Google App Engine <google-appengine@googlegroups.com> > Sent: Thu, 8 July, 2010 7:07:19 > Subject: [google-appengine] Re: list-property, many to many, 5000 > indexes...HELP! > > oh, wait. If I replace your word 'stream' with 'follower' like a > twitter follower, then I think it immediately makes a lot more sense. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to google-appeng...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
