Abstraction of statuses from users

This is on my long-term to-do list, up there in the nether with comments. Technically speaking, the core implementation is actually pretty easy--the status update form has to run some logic to figure out that it's being shown on a group, and then when it saves a status, there would have to be another column on the {facebook_status} table to hold the group ID. The complicated part is writing the Views integration, mainly because there would need to be filters to exclude statuses posted to private groups as well as groups in general. OG integration should also have a separate API, but I don't really care about that.

So if and when I do this, it will probably be as a submodule. If you get something rolling, the whole process will move a lot faster. The core functionality would be in an implementation of hook_facebook_status_save(). You can ignore pretty much everything else for now, although Views integration is pretty crucial at some point obviously.

Thanks for the pointers. I was thinking of this in another direction... Basically:

type: node or user
eid: (entity id) This is the ID of what the status is attached to, either node ID or user ID, depending on type.
sid: uid of the person sending the status
rid: uid of the person (if any) receiving the status

Then you can have a view of all statuses, all node statuses, all user statuses, or filter statuses to a particular type/id combination.

This would disconnect streams from users a bit and make it so you could potentially attach a stream to anything, much like fields are getting disconnected from nodes. :) You could even add taxonomy in there and have a stream per taxonomy term.

I haven't actually tried to code any of this. I see your API is well documented, though, which is great. I'll have to give it some more thought but I worry that my ideas may be too radical for you to fold back into the module itself. :(

Michelle

That makes sense--I was essentially thinking the same thing except I wasn't thinking of abstracting it to another level. There would still have to be at least one filter written explicitly for OG integration because of the complication of having private groups though.

FWIW, the current database schema is here. Essentially from what you're proposing UID would change to EID and a "type" column would be added. That's completely feasible although it would require much more sweeping changes because the API signatures would all change and all the DB queries in them would change as well.

I actually really like this idea, although it will be months before I can even think about committing the amount of time this would require. If Author Pane had views integration and this proposal got in to FBSS, FBSS could potentially even be a complete replacement for the comment system in addition to all its other uses.

Sounds like postponed is a good status. It doesn't make sense for me to hack together something when this really needs some re-architecting to make it work. It's one of those "would be nice" things on my site but I can get along without it. Why don't we talk more when you have time?

Michelle

Works for me. I may just throw in a few final fixes to the 2.x branch, release a full 2.0, and then slate this as the first feature to go into 3.x. That will hopefully make the transition easier for most people and keep from overhauling the API when we're already at RC2 for this branch, and will give me some direction for 3.x because I still haven't decided on a Publisher implementation.

That sounds like a good plan. :)

I wish we could fast forward sometimes... I think separating the stream from users will open up a lot of possibilities, especially once comments are added for a full conversational experience. Microblogging on an organic group is awesome if the folks want to get together for a quick chat. I'm sure there are other uses for it as well. Maybe for wiki pages to have a "discussion" tab? This has a ton of potential.

Michelle

I completely agree. Technology rocks. :D I've reworked the roadmap for 3.x, by the way--you may want to take a look.

Sounds great! Can we just skip 2.x and have 3.x come out tomorrow, please? ;)

Michelle

It would be great to have a "full Facebook-style Publisher" but for DRUPL 6 not for DRUPL 7.
I think that drupal 7 takes lot of time before it becomes release and you have to wait that all the others modules (OG, notification, etc..) will be developed for Drupal 7.

I suggest you the develpoement for Drupal 6....first of all for those features:

- pubblish photo
- Userpoints integration
- Comments on statuses

Carlos

This issue is unrelated to plans for a Publisher; please keep it on-topic. (And anyway, if D7CX continues strong and test coverage does as much for bug-squashing in core as some seem to think it will, it's fairly likely that I won't even get around to starting a Publisher implementation until after D7 and many major contributed modules are already out and stable.)

Note to self: abstracting statuses from users also implies the use of the type_options property in hook_activity_info.