I am looking at the module and see that it depends on 'buddylist', which is the old module, removed in Buddylist 2.

Does Activity have any real dependencies on the old buddylist or merely uses the same database schema? Is there any ongoing effort to update it to Buddylist 2? It seems to me this should be done in 5.x-3.x release of this module.

Comments

robertdouglass’s picture

robertdouglass commented

The DRUPAL-5--3 branch no longer has a dependency on buddylist. Any integration with other modules is done in the activity/contrib/ directory in the form of modules that implement two hooks. I won't be writing a buddylist 2 integration module but it is very easy to do, and you can follow the current examples to find out how.

robertdouglass’s picture

robertdouglass commented

The DRUPAL-5--3 branch no longer has a dependency on buddylist. Any integration with other modules is done in the activity/contrib/ directory in the form of modules that implement two hooks. I won't be writing a buddylist 2 integration module but it is very easy to do, and you can follow the current examples to find out how.

dkruglyak’s picture

dkruglyak commented

Great, look forward to trying out DRUPAL-5--3 branch to see how well it works.

When do you expect the code to be stable enough (e.g. not changing on a daily basis like today) ?

sirkitree’s picture

sirkitree commented

good question ;)

I've been doing some testing of robert's changes and new features and it's looking good. There's one critical bug that I found so far( http://drupal.org/node/205746), but that's a simple fix.

/me runs off to do some more testing.

dkruglyak’s picture

dkruglyak commented
Title: Support for Buddy API a.k.a Buddylist 2 ??? » Integrate Buddy API with Activity
Project: Activity » Buddylist
Version: 5.x-3.x-dev » 5.x-1.x-dev

As I am starting to review Activity (DRUPAL-5--3) this brings up a few thoughts on integration with Buddylist2.

Activity looks like a great module to provide a persistent datastore of user actions - supported by many contrib modules. However, I am not sure merely writing a Buddylist2 plugin contributed to Activity is the way to go.

A great thing about Buddy API is delegating functionality to best-of-breed modules, like Views (display of buddies & requests) and Workflow NG (sending requests / notifications). Activity looks like another module that could plug into Buddy API, not only to record friend maintenance actions (like add/remove) - but to track activities *between* buddies, once friendship is formed.

Among the simplest improvements this could mean making Activity data retrievable through Views and linked (in messaging and notification behavior) with Workflow NG. This could make Activity items act like requests in Buddylist 2.

At a deeper level this could lead to extending Buddy API to generate activity between buddies (one- or two- way), which in turn could be exposed to contrib modules to build actions around the Buddylist. The kind of stuff you find in Facebook apps.

FInal step could be creation of a Buddy Request API to go beyond merely recording the activities between buddies, but make them actionable. In a way this would be a generalization of existing buddy requests API to arbitrary requests.

Marking this as an issue to consider for Buddylist 2.

nodestroy’s picture

nodestroy commented

sounds great, a complete system which is able to record all activities between buddies would be greate!

maybe we can think about further details when both modules are stable, so that there are no more fundamental changes.

nodestroy’s picture

nodestroy commented

what about this:

- providing a dynamic choice between one/two way relation. (userA clicks "add userB to buddylist" -> page with options: relation type AND one/twoway), so the users could decide which connection type should be initialized
- providing api functions for other modules, to add relation types, so there could be many types of buddy connections

for sure, that’s not what you are talking about. The facebook system is a closed system of modules, which are optimized for working together. Imagine, you have a website with a photo gallery (or event calendar,...) and you need buddy_api for the request to add a photo tag. In my eyes there would be too many dependencies.

Maybe there could be an own "request" module, which handles all kind of requests (buddy requests, event invitations, photo tag requests,...). Modules like buddylist and event calendar could be two modules on the same "hierarchy", which use both the request module to send requests to other users.

dkruglyak’s picture

dkruglyak commented
Title: Integrate Buddy API with Activity » Design for Buddy Activity API

Great comments. I think both Buddylist and Activity modules are stable enough to start development. Which should be done sooner rather than later, given the need to fix the one-way friending issue (per http://drupal.org/node/203500)

I see your point about making a standalone "Request" module independent of Buddylist / Buddy API, providing service to modules such as Groups, Events or any custom modules. Perhaps requests could even be made part of Activity module. However, the most natural way to start creating this request module is by moving existing request functionality out of Buddy API (fixing http://drupal.org/node/203500 in process). There is another reason to keep requests within Buddy API package - the types of allowed requests should be dependent on existence of a friend relationship (or its type one/two way). Finally, a request service provided to contrib modules should include a basic friend selector control. This is another vote for keeping requests together with Buddy API.

So my proposal is a Buddy Activity API module - integrating Buddy API with Activity and providing a request API. Suggested design:

[1] Objectives of the Module

A) Create a flexible API
* Enable API for requests between buddies (or non-buddies)
* Provide proof-of-concept for implementing request API (by Buddylist2)

B) Integration and Migration
* Integrate Activities module to track activities between buddies (or non-buddies)
* Extend and migrate existing request table to support any request type
* Use Views and Workflow-NG to display and control all Activities and Requests

C) Fix pending issues
* Resolve the limitations of one-way Buddy API mode
* Create request mechanism for collecting friend details (for later)

[2] Comparison to Facebook

A) Supported APIs
* Generate requests by calling module's function(s)
* Extend Buddy API to support friends.get and friends.areFriends
* Provide friend selectors for requests invoked by contrib modules

B) Activity types
* Invite request: Provided by the new Request API
* Newsfeed / mini-feed: Provided by Activity module (pending http://drupal.org/node/209693)
* Notifications: Provided by Activity module (scope = ACTIVITY_SCOPE_SELF)

Reference -
http://wiki.developers.facebook.com/index.php/Request
http://wiki.developers.facebook.com/index.php/Fb:request-form
http://wiki.developers.facebook.com/index.php/Fb:req-choice
http://wiki.developers.facebook.com/index.php/Fb:request-form-submit

[3] Implementation Tasks

A) Create Buddy Activity API module
B) Move out all request functions out of Buddy API
C) Modify buddylist_pending_requests table to support generic requests
D) Retool Buddy API views to support all requests and Activities too
E) Retool Buddy API workflows to support all requests and publish Activities
F) Update Buddy UI to use new Request API

Future tasks can be added once this basic design is implemented. Ultimately this module could be made standalone or part of Activity.

robertdouglass’s picture

robertdouglass commented

The one last change to Activity 5-3 I want to make before a release is to allow different wording in the message for ACTIVITY_SCOPE_SELF so that you can have messages like "You invited Bob to be your friend" on a person's own message feed.

After that I'm going to make a release and can then think about this generalized request API.

dkruglyak’s picture

dkruglyak commented

I think it is worth adding support for Views directly into Activity module. Of course via Usernode just like Buddylist2.

This should make further customization of labels a snap and more importantly enable any customized selection and display of activities (e.g notification page, various mini-feeds, application / module feeds, etc.). The number of needed displays may be infinite.

If you would like to adopt Requests into Activity module, I think that would be awesome.

sirkitree’s picture

sirkitree commented

Views support for activity has been something I've been thinking about, but not sure how that'll work since it's not really node based. What kinds of things do you think would be good to expose to views?

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

Just subscribing, sorry... Hate bumping it but I want to see where this goes as I'll be integrating activity into advanced profile.

Michelle

dkruglyak’s picture

dkruglyak commented

Every Activity field should be exposed as view field. All kinds of filters and sorts should be possible on these fields.

Take a look at how Buddylist2 implements views for buddy table (check out DRUPAL-5--2 branch from buddylist CVS). This module depends on Usernode to provide user-to-node glue required by views and comes with very good default buddy views.

nodestroy’s picture

nodestroy commented

To provide a faster development of buddylist2 i have created a new project
http://drupal.org/project/buddylist2 (so that there is no confusion at [old] buddylist issue queue)

a dev release will be out in the next 12 hours

@dkruglyak: you proposal sounds great, but I wan´t to add something (important?): Buddylist2 (mainly buddy_api and buddylist_ui) should be very easy to install and modify. the complexity in compare to old buddylist module should not be upscaled very much. (furthermore the dependencies should be minimal)

the actual state is (buddy_api & buddylist_ui):
- drupal 5: dependencies on: usernode & views [& workflow_ng & token]
- drupal 6: dependencies on: views [& workflow_ng & token]

it would be great, that buddylist2 is as easy to install like buddylist and has more functions and more possibilities to extend.

dkruglyak’s picture

dkruglyak commented

As far as dependencies are concerned there is a little dilemma here.

Either Buddy API has its own request mechanism or it is farmed out into a dependent module. Right now requests are part of the Buddy API and this is the cause of the problems that bring about this issue to begin with.

So I think dependency on a new request module is not a big price to pay. Either it should be a new standalone module (perhaps part of Buddylist2 package) or part of Activity module. In the first case dependency on Activity could be optional.

In any case the Request API would be very simple and low overhead.

UPDATE: Latest changes to Activity module make it an excellent place to put the request API. Key issues discussed here -
http://drupal.org/node/209693#comment-700746