Merge Shoutbox and Facebook-style Statuses (Microblog) [Drupal 7]

Facebook-style Statuses (FBSS) 2.x literally has every single feature of Shoutbox plus many more, except for the ability to post messages on groups. However that ability is in the 3.x branch. So while (as the maintainer of FBSS) I'm open to working with Shoutbox and accepting ideas from it, it is more likely that "merging" would simply mean that Shoutbox became obsolete and died. If the Shoutbox maintainers want to pursue that path, I will be happy to provide an upgrade path from Shoutbox to FBSS 3.x.

This is actually something I've discussed with Jay Batson (Acquia VP) since Acquia is basically maintaining Shoutbox now since they chose to use it for Drupal Commons. Jay said that they would look at using FBSS instead of Shoutbox when Commons moved to Drupal 7.

Funny, I recently committed shoutbox_tags (#hashtag) functionality..

Umm.. I don't know what to think.

Anyone have any feedback - maybe people who have used both modules?

Mike, I'm not going to press you on this -- if I was going to, I would have brought it up myself months ago -- but if you'd like to discuss, feel free to contact me (use my contact form and we can set up a time to talk on the phone or IRC). I do think it would be a good idea to discuss before we work on (or at least get very far on) D7 versions, since Shoutbox does seem to be moving in the direction of FBSS and away from what I remember to be its roots as a lightweight chat. FBSS is a few steps ahead of Shoutbox in some important areas, and if you're interested in working with me on a D7 branch I would welcome the help.

Yeah I think it makes sense. I just don't want to be unfair to people who are using and liking shoutbox. If people were up for it, then maybe we could put together a migration script or something.

I do agree that the 'status' and 'twitter'-like micro-messaging is what people want more now, and is what they're used to.. so it probably is a good idea.

I feel the same way. That's why I think it would be better to discuss this for D7, because a D7 branch of Shoutbox doesn't exist yet (AFAICT) so it's much less trouble for users to migrate. I'd be happy to write an upgrade script from Shoutbox to FBSS at any stage though.

Triple quaDrupal bump.

I hope this means that it will still be possible to "shout" only locally, and not be forced to publish or syndicate shouts outside the actual web site?

"Facebook-style" means "like Facebook but in Drupal," not "post to Facebook," if that's what you're asking.

So the Facebook-style Status module is actually a Twitter/Facebook/(fill-in-you-favorite-status-service) style status module. It's meant to emulate the functionality of these services.

Hi,

for my part, I like the fact that Shoutbox is small and doing only one thing; I'm not trying to duplicate Facebook with my web community. I'm trying to do something else.

I can understand that maintaining a «one function» module is not a big challange for a programmer. Anyway, this is only the point of view.

Thanks for the hard work! And a great 2011 year!!

R.

+ 1

- 1

Subscribe.

Because there are too many changes in D7: maybe build a new module for D7 (like, "walls", hope that it is not trademarked by Fb), deprecate shoutbox & fbss, and provide a migration path for both shoutbox & fbss. That sounds good for me, because fbss will any way change its name in D7.

There was an effort to build a similar module in D7 http://drupal.org/project/walls. But it looks like abandonned after having received an alert from fbss ;)

+10,000

I have to agree with #11 - these are still very different modules, especially if you look back to the 1.x branch, which I've sort of rudely began to over-complicate with the 2.x, removing some simple aspects, and especially, more friendly anonymous support.

Has anyone looked into what it would take to migrate data from shoutbox to fbss? I'd have to think that would be a very important part of this discussion.

Could both be an option? Could an upgrade path be provided for those that want to jump ship AND shoutbox can continue doing its thing?

They are not the same, but technically they will be the same in D7. None is ported to D7, so I suggested to make a new module, with the best architecture and best features of both.

Let me offer some insight into why I think merging Shoutbox and FBSS would be a good thing. I'm going to use the neutral word "message" to mean "shout" for Shoutbox and "status" for FBSS.

Things Shoutbox has that FBSS doesn't

• Support for anonymous users to post messages. This is not trivial to add to FBSS.
• Built-in moderation for messages. FBSS makes this possible through integration with the Flag module.
• Messages can expire after a certain amount of time. This looks like a vestigial feature in Shoutbox from the old version when it was more like a chatbox. I've actually written this feature for FBSS but not published it because I think it's dangerous to delete data.

Of these reasons, support for anonymous users is the most compelling reason to choose Shoutbox over FBSS.

Things FBSS has that Shoutbox doesn't

• Much greater flexibility:
  • A more complete API for manipulation of messages
  • An extensible context system that allows attaching status streams to anything with only about 30 lines of code (status streams can be attached to users, nodes, and groups by default)
  • Any part(s) of the page can be automatically refreshed after saving a status via AJAX -- not just the associated list of messages
• Threaded conversations are supported between users
• Lists of messages are displayed using Views, making it much easier for administrators to control what the message lists look like
• Messages can be viewed on their own pages, so they can be linked from other websites
• Administrators can send messages to all users
• Integration with over 20 other modules. This allows things like "liking" messages like on Facebook; "following" users like on Twitter; posting messages to Twitter from Drupal; notifying users when they receive new messages; and viewing "friends' messages."
• Links for users to "respond" or "re-post"/"share" messages like on Facebook
• Support for attaching media and comments (media support hasn't been ported to 3.x yet)
• The algorithm for matching #hashtags and @mentions is better. It supports multi-word tags/names as well as international characters, and it's faster. It also provides "popular tags" blocks and supports Views so that users can create lists of messages that mention them, etc.

Additionally, all of this functionality does not come at the cost of bloating. FBSS 3.x is almost as efficient as Shoutbox because most of the code is loaded conditionally so it's only in memory if it's needed on that page. For example shoutbox.module is 1296 lines and facebook_status.module is 1084 lines (although this isn't a particularly good measure since FBSS often has other code loaded). Also most of the integrations have been split out into submodules so you can enable or disable the features you need.

I think it goes without saying that adding all of these things to Shoutbox would be quite difficult.

Things to consider

The things listed above are reasons to choose Shoutbox or FBSS, not reasons to join forces (or not join forces). It's just for perspective. To consider whether we should join forces, we really need to consider only two things: the purpose of each module, and what features are planned for each module moving forward. If the purposes are the same or the (planned) feature set overlap significantly, we should join together. I believe that both things are true.

The purpose of FBSS is to provide a way for users to create content with the minimum entry barrier. To this end, FBSS is a module that lets users post messages in various places by writing text in a small textarea and having that text saved via AJAX. One of my goals for FBSS is flexibility, by which I mean extensibility and integration: I think that there's a lot of potential for easier ways to post various kinds of content, and I want to make that possible without a cluttered interface, too much overhead, or additional complexity for administrators. In order to do this, I've put a lot of effort into FBSS' API, as well as adding various toggle-able features common to systems with simple ways to post content.

As I understand it, Shoutbox started out as basically a chat module and has since turned into a simple way to post content on group and user pages. That's basically the same thing as FBSS, just with a slightly more restricted worldview. FBSS does this out of the box -- it's just that it can be extended to do more if necessary.

As far as feature sets go, the feature set of FBSS is basically a superset of the features of Shoutbox, except that FBSS doesn't support anonymous users. But that's a reasonable feature to add to FBSS and we could work on that together. Maybe flexibility/extensibility/integrations is not so much a goal of Shoutbox, but FBSS structures this in a way that the flexibility doesn't interfere with anything if you just want to use the base features. And it seems to me like the things FBSS has that Shoutbox doesn't would be nice additions to Shoutbox; so if there are any plans to work on this type of thing anyway, it would be better to work together and reduce redundancy.

Looking at the schema of Shoutbox versus FBSS, it looks like the data would be very straightforward to port. The only thing, again, is that FBSS doesn't support anonymous users, so that feature would have to be added first. But it hardly seems worth having two separate modules that do very similar things just for that one difference.

Build a completely new module?

No, that's silly. Shoutbox and FBSS are both solid platforms. There's no reason to throw all that work away and start from the beginning; you'd be rewriting most of the same code. It makes much more sense to just start with one (probably FBSS, because it's more powerful and has relatively fewer missing features) and build the features of the other into it.

The only significant reason to rewrite substantial parts of the code for D7 would be to take advantage of fields to allow attaching various kinds of media to messages. However that is an addition of code on top of whatever already exists; it doesn't really require extensive changes to existing code. Additionally, it's not as simple as just adding fields integration. A new UI would need to be created on top of fields so that the message form is not just a big list of of fields; like the FBSMP add-on for FBSS does now, you should be able to click on an icon for the type of media you want to add and have the field(s) to attach that media magically appear.

sub...

+1

IMO, it is important to have the option of just installing a simple chat module with no dependencies.

Example: When establishing new sites on new versions of Drupal, for example just for evaluating and testing, then a chatbox is an invaluable tool. Too bad if we have to wait for it because of other features we dont need in that context. That has been the situation for D7. We are now a very long way into a new platform, and still that part is missing.

Simple also in the sense that complexity-related bugs would not creep into it "unnecessarily", and that any "integration" with other modules are optional and not a development roadblock. A modular approach as to what gets enabled by default (and is needed) is important, IMO.

Shoutbox has integration option with Organic Grups, for example, and will the FBSS module have dependencies on for example the Views module? What has been the situation in practise: has the OG integration effort taken time away from porting the basic functionality to D7? Would bugs related to such integration actually block stable release of the core chatbox functionality?

I think it is absolutely critical to have basic chatbox functionality with no external dependencies other than on core modules.

The general complexity of Drupal sites is increasing - which is not all good.
Here is an example from the FBSS issue queue itself:
(https://drupal.org/node/671822#comment-4394184)
Comment #31 :
"For all those subscribing, the major blocker to a 6.x-3.x release candidate (and therefore the major blocker to a D7 port) is the instability of the comments submodule. "

The instability of a submodule is blocking a port of a basic function for the new platform.
Without having dug into that particular issue, I wonder if that sub-module is even relevant for the functionality of a basic chat box.

What kind of situation do we want to have when we move from D7 to D8, and then further to D9?
Complexity-related roadblocks, or simple stand-alone modules which offers extensibility in a way that does not block the usage or the development of the basic features?

Would it be programmatically difficult to merge them in such a way that it is possible to use only the core functionality of a chat box without enabling the rest? Even use it even if the "rest" is unfinished? The default mode of the module could be a "light" variant, almost like Shoutbox, and then people could enable more features on the configuration page at will, and as they became stable and ready.

We know that we will have a microblogging solution available anyway, even if as a separate module.
That should not prevent us from having a basic chatbox feature at an early stage of new Drupal releases.

So, I am basically in favor of merging all complex features over into FBSS, but retain the very basic shoutbox functionality in a module that can work by itself and will be easy to port to the next platform.

IMO, it is important to have the option of just installing a simple chat module with no dependencies.

FBSS depends only on Views which is already used on about half of Drupal sites, and it was designed to load the minimum possible amount of code per page, so it's definitely not bloated. The size of the download reflects the fact that FBSS has a bunch of submodules that enable various integrations.

Simple also in the sense that complexity-related bugs would not creep into it "unnecessarily", and that any "integration" with other modules are optional and not a development roadblock.

FBSS and Shoutbox are both very stable. Only 1.3% of the total number of issues against FBSS are open bugs (the number is 9.6% for Shoutbox). To me it's absurd to say that you will allow a supposedly stable release if there is broken functionality in it, whether it's integration or not. That's not to say that you can't use the module before a release candidate (in an alpha or beta release) and just take advantage of what is stable if you want. And anyway, FBSS has had a release candidate for 6.x-3.x for a month or so now.

Complexity-related roadblocks, or simple stand-alone modules which offers extensibility in a way that does not block the usage or the development of the basic features?

The other side of that argument is that people want something that they can just download without chasing down lots of dependencies. Modularity comes at the cost of simplicity, and we're all trying to find the right balance.

Would it be programmatically difficult to merge them in such a way that it is possible to use only the core functionality of a chat box without enabling the rest? Even use it even if the "rest" is unfinished? The default mode of the module could be a "light" variant, almost like Shoutbox, and then people could enable more features on the configuration page at will, and as they became stable and ready.

That is exactly how FBSS works.

I realize that the usage of both Shoutbox and FBSS have continously decreased since 8-10 months. Is there any new related module that we should focus on ?
http://drupal.org/project/usage/shoutbox
http://drupal.org/project/usage/facebook_status

That is exactly how FBSS works.

If we look at the folder structure, we'll see that both modules work that way: there are plenty sub modules for integration.

But sadly, as Taxoman pointed out, put sub modules in the same code base make it impossible for separate upgrade.

Just for the record, I am not out to critisize the developers or anything like that, just add my 2 cents regarding the strategy and way forward.

The situation we are in right now speaks for itself:
- when I started testing and getting ready for D7 last autumn, that is when I needed a basic chat box functionality the first time on D7. Now - roughly 10 months later, that situation has not changed: I still need it, and still dont have an option on D7. And now - 7 months into the new platform - this counts for an alarming amount of people and web sites.

My point is that I fear this will repeat itself when we go for D8, unless we make strategic choices that prevents it already now.

I might as well put it out there: I'm working at Acquia over the summer, and Commons 2.0 and later will have FBSS in it instead of Shoutbox.

I realize that the usage of both Shoutbox and FBSS have continously decreased since 8-10 months.

Those numbers are wrong. Usage stats on d.o also report that usage of Core has not gone up since D7 was released. There are a number of things that could account for the usage chart numbers, such as improvements to the counting algorithm to weed out cheating, fewer people enabling Update Status in D7, and maybe people are just willing to upgrade to D7 without Shoutbox or FBSS on the premise that they'll reinstall it when there is a D7 version. In any case, there are no better alternatives.

put sub modules in the same code base make it impossible for separate upgrade.

No. Having submodules in the same project means that the entire project will not be tagged as "stable" until the submodules are stable. However you can still use alpha and beta releases where the core module is stable and the submodules are not. The only difference is the name of the tag. Additionally, having submodules outside of the main project makes them much more likely to be abandoned because they won't get the same amount of attention; and it adds more burden on administrators to have to go chase down several modules to install.

I am not interested in responding to any more complaints that FBSS or Shoutbox has not been upgraded to D7 quickly enough. I know that lots of people want a D7 version and believe me I want one just as badly. The bottom line of this issue for me is that Shoutbox has fundamentally the same goals as FBSS, and no less complexity, but fewer features and less flexibility. Because of this, I would like to get some feedback from disterics about collaborating to reduce duplication and confusion.

@IceCreamYou/#28:
I hope we can discuss how to avoid the current situation re-occurring between D7 and D8 by merging these projects, without this being seen as a complaint to anything. Just as a strategic discussion.

I would like to hear your opinion on two specific issues:

a) Would you be positive towards having the "core" part of the new module without dependencies (as a strategic element so that more people can feel sure that this will persist and not change later) that includes a chatbox feature?

What gets enabled on the first step is just the core features, no dependencies other than towards Drupal core modules, along with just a basic chatbox. Then, to enable further sub-modules, one might have to have Views etc. enabled, but can still use the basic functionality by itself. Fancier chatbox features etc. might then be dependent on other modules such as Views, but enabled as sub-modules when desired.

b) With a situation as in a), would that make it easy to release a port of the "core" part of the new module version to new platforms such as D8 and D9 even before _any_ sub-modules have been ported?

It would be interesting to know if you think these concerns are valid and interesting and worth pursuing, especially given the fact that you indeed try to convince the community to support merging these modules. (I am generally in favor of merging, if these issues are addressed).

Anyway - the problem of the D7 port of Shoultbox is obviously a Shoutbox issue, not to blame on FBSS, but as we already have such concerns to address, then I think this is the time and "place" to address them, right now in the discussion about how to move forward. A merge has the chance to become a positive addition and solution to the current Shoutbox situation.

Alternatively, all but the core Shoutbox features could be "moved" over to FBSS (removed from Shoutbox), in order to keep Shoutbox simple and small in the current project, and make it much(?) easier to maintain between future platform upgrades.

Alpha and beta releases of FBSS ports between major versions will have the main module stable. These are totally usable without the submodules being stable. That's basically the definition of an alpha/beta release, and there is no technical distinction between doing it that way and having the main module in a separate project. Therefore, having submodules in the module's package does not hold back a port -- it just delays what is tagged as the "officially, completely stable" version. On the positive side, having submodules in the package makes sure they get the attention they need and makes it easier for less-technical people to install everything they need. And if you install a beta then Update Status will automatically notify you when there are newer releases that have the submodules stable.

The idea that submodules hold back porting the main module is a red herring. FBSS isn't ported to D7 yet because I focused on the 6.x-3.x branch first, not because it's too big to manage. There was a 2-week period before the RC for that branch where I was pushing to complete the comments submodule before tagging the release candidate. That's an insignificant time period, and the main module was totally usable in beta form.

If it turns out that a submodule that provides integration with another module is unduly difficult to port between major versions, I would just leave it out until that is no longer the case. Integrations are not generally release-blockers.