I just had a very productive conversation with arithmetric about a "Buddy List" submodule that could come with the Node.Js integration module. Ideally, applications like tic tac toe or (any node.js game) could use this buddy list submodule to allow users to see which of their friends is online. Maybe we could even make this more accessible by allowing anonymous users to have temporary "accounts" (identified by cookie or similiar) that could have buddy lists so people aren't required (yet encouraged) to register at your drupal site.

I would also say facebook connect node.js buddy list but the d7 version of it is still in dev.

Is anything like this in the works?

Comments

Anonymous’s picture

Anonymous (not verified) commented

no, but yes please! arithmetric++ LSU_JBob++

LSU_JBob’s picture

LSU_JBob commented

Sweet, I wanna figure out some good starting points to this. We're going to have a small code sprint for this tomorrow (June 18th 2011) from 12PM EST to 4PM EST. We'll see what we can hash out.

LSU_JBob’s picture

LSU_JBob commented

Three blocks:

  1. A "see everyone" block, everyone that is logged onto the main channel (for admins maybe)
  2. A "see users per channel" and have channel be the argument (for D7 chatroom?)
  3. A "my buddies" block

other stuff?

  • Form for user to set their buddy list? an auto complete field where you can append a list which is a serilaized object stored in an extra column in the user table, or we just make a new table with a 1-to-1 relationship to user and store the blob in there. OR We could just create a dependency on the User Relationships module and programatically create relationships through that API.
  • Ajax callbacks for adding and dropping buddies quickly?
  • Defining Drupal.Nodejs.callbacks.buddyList.callback
  • admin settings form and all the stuff that entails (saving/editing settings)
  • What else?
arithmetric’s picture

arithmetric commented

My two cents:

  • I think it's best to let User Relationships or Friend Flag handle the management of the buddy lists, and have the focus of this submodule be providing a real-time interface for keeping the list of active/online friends up to date.
  • In addition to the blocks (which are great for providing out-of-the-box functionality), I'd suggest making the buddy list data accessible in JavaScript so that other client-side applications could easily integrate the buddy list within their interface.
LSU_JBob’s picture

LSU_JBob commented

Great, thank you arithmetric.

I've made a github repo for this submodule.

https://github.com/johnrobertwilson/Node.js-Buddylist

We also decided to have the back end of the friend logic be managed by Flag and Flag Friend

Anonymous’s picture

Anonymous (not verified) commented

I like where this going.

LSU_JBob, lets keep the code on d.o. ok?

LSU_JBob’s picture

LSU_JBob commented

sure, i just didn't want to commit bad code.

I should commit it to the dev branch yes?

arithmetric’s picture

arithmetric commented

After thinking more on this project, I realize that there's more to do than make flag_friend's buddy list data available through the node.js service. We also need to provide the code for identifying which users are online.

Older buddy list modules would have determined this based on the last time that Drupal saw a given user (i.e. the last time a user hit a page on the Drupal site). This would have given a fuzzy result for whether a user was online, as it would need to allow buffer time since the last hit in case the user is still at the site but sitting on a page.

We could take a new approach and delegate to the node.js service the task of evaluating whether the user is online or not. By maintaining a persistent socket while the user is on a page and dispatching events when a client connects or disconnects, the node.js service is well suited for keeping track of whether a user is on the site. This functionality could be built as a server extension.

The main caveat is that this will only track users who connect to the node.js service (have a compatible browser and JavaScript enabled).

What do you think?

Anonymous’s picture

Anonymous (not verified) commented

thinking of committing this as comments to server.js, which is a distillation of a discussion we just had on presence stuff in the ampersand tech office:

/**
 * 1. Presence notifications, triggered by connect and disconnect events.
 * 2. We keep a list, keyed by uid, of uids allowed to see presence changes
 *    for that uid key.
 * 3. Drupal will send a) list of people user is allowed to see, and b) list of
 *    users allowed to see user.
 * 4. List from 3. a) is iterated over on node.js end:
 *    for (var uidUserCanWatch in listOfUidsUserCanWatch) {
 *      userPresenceChannels[uidUserCanWatch].push(uidOfUser);
 *    }
 * 5. List from 3. b) is simply added to userPresenceChannels:
 *    userPresenceChannels[uidOfUser] = listOfUidsWhoCanWatchMe;
 * 6. Don't send disconnect without a setTimeout on the event first, so we
 *    don't send spurious updates
 * 7. Drupal has a boolean for online for all users. We send auth, so drupal
 *    can use that for the online event, and we send disconnect. We need to 
 *    handle multiple http sessions gracefully. We want this at the scope of
 *    the uid, not the http session.
 * 8. Allow clients to fetch the presence lists via node.js.
 */
LSU_JBob’s picture

LSU_JBob commented

Useful in our case!

Anonymous’s picture

Anonymous (not verified) commented

ok, i committed a slightly modified version here:

http://drupalcode.org/project/nodejs.git/commit/1e6a4cb

Anonymous’s picture

Anonymous (not verified) commented

the other thing to note is that i think a chunk of this will go in server.js, and some into nodejs.module.

i think these are low level enough that we should add them as primitives to the node.js server and core module, then devs can extend them as they see fit.

LSU_JBob’s picture

LSU_JBob commented

http://drupalcode.org/project/nodejs.git/commit/b0fc46b

Initial commit after the nyc drupal playday on 6/18/2011

Feel free to completely rip the code up. Let's talk more about what's going into the core module and what we need to call from this one. I like this "presence lists" idea.

LSU_JBob’s picture

LSU_JBob commented

So let's talk about this presence lists thing. I was going to add some "add user to channel" stuff for admin view and what not but feel like presence lists would make that redundant.

Anonymous’s picture

Anonymous (not verified) commented

a couple of relevant commits:

http://drupalcode.org/project/nodejs.git/commit/3b96e18

http://drupalcode.org/project/nodejs.git/commit/53d606a

add the basics of presence notifications to the core of nodejs.module and server.js.

will try to catch LSU_JBob in IRC to discuss the next bits.

LSU_JBob’s picture

LSU_JBob commented

Awesome, thanks justinrandell, taking a look at this this week.

  • Commit 1e6a4cb on 7.x-1.x, drupalconlondon, auth-refactor, 8.x-1.x, 8.x-1.x-head by beejeebus: 
    #1191224: document current thinking on presence design