Hi Brian, Great you brought this up, activity stream will be a great addition to Pinax IMO
I started to look for a solution few months back and I couldn't find what i wanted in Pinax. ericflo created great activity stream server (AwesomeStream), I started to work on a client and enabled comments and likes/dislikes, I was going to continue the work and planned to integrate it with Pinax (django-friends and django-avatars), but I've stopped since ericflo seemed to lose interest in AwesomeStream in-favor of Solr. What is interesting in AwesomeStream approach, is the events are posted once and there are no redundant copies of the event for each friend, and the stream is retrieved based on the relation with the user, so we dont have to send updates for each and every friend. My plan was to make the activity stream the home page of the user, where the user can post updates, or read, comment, and like/dislike his friends updates and activities, the updates or activity stream could be generated by the user and internal/external applications. In my case I have a game server that will be generating events based on the user activities or scores, I wanted the activity stream to include media (images, videos, etc) and not only plain text. I'm very interested in having activity stream in Pinax, and I'm willing to spend sometime on that. Ahmad Al-Ibrahim On Sat, Feb 13, 2010 at 3:18 PM, Brian Rosner <[email protected]> wrote: > Hey all — > > I've been doing some thinking lately about how we handle events in Pinax. > Let > me first define an event. An event is an occurrence of a voluntarily > action. > Examples of these include: > > * user A joined project B > * user A updated their avatar > * user A became friends with user B > > Currently, we have blurred the line between an occurrence and action taken > from the occurrence. This is called django-notification. There is overlap > between the way we are handling this and something like an activity stream. > We have on-site notifications which try to emulate an activity stream, but > in my opinion fails horribly at it. Notifications must be sent to users. > This > becomes problematic when the action you want to take is to notify an IRC > channel for example. > > I'd like to propose a change. At this point this change won't be in > django-notification. Just replace its use as the event emitter. It had been > discussed in the past to use signals. I think this is a good use-case for > using them. > > I see two direct benefits from this approach: > > * don't need to enforce apps to optionally support django-notification > * listener code is project-level which can depend on anything the project > does > (solves cases like when avatar is updated let all friends of the user know > they've updated their avatar) > > To demostrate (code style below designed for brevity): > > # django-avatar signals.py > import django.dispatch > avatar_updated = django.dispatch.Signal(providing_args=["user", > "avatar"]) > > # django-avatar views.py > from avatar import signals > def change(request, ...): > ... code that handles request and makes Avatar object > signals.avatar_updated.send(sender=request, user=request.user, > avatar=avatar) > ... rest of view ... > > # project-level app (no name decided yet, but working name is > request_events) > # handlers.py > from notification import models as notification > from friends.models import Friendship > def avatar_updated(sender, **kwargs): > request = sender > ctx = { > "user": kwargs.get("user"), > "avatar": kwargs.get("avatar"), > } > notification.send([request.user], "avatar_updated", ctx) > friends = f["friend"] for f in > Friendship.objects.friends_for_user(request.user) > notification.send(friends, "avatar_friend_updated", ctx) > # models.py > import avatar.signals > from request_events import handlers > avatar.signals.avatar_updated.connect(handlers.avatar_changed) > > I'd like to gather thoughts from people. Based on the advantages > above this seems like a win to me. If we are in agreement with the > direction > of this change I plan to integrate this at PyCon for 0.9 alpha. > > Brian Rosner > http://oebfare.com > http://twitter.com/brosner > > -- > You received this message because you are subscribed to the Google Groups > "Pinax Core Development" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<pinax-core-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/pinax-core-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Pinax Core Development" 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/pinax-core-dev?hl=en.
