Similar module - differences from Bean module?

Yes, duplicating efforts is a waste of time. Absolutely in favor of that.

However, someone would have to step up and coordinate this, getting the maintainers together (basically on a round table), to discuss things like project name ("bean", what a confusing term?), project/git access, roadmap, and so on.

Lastly, please note that the core of block_api module is not about blocks as plugins, or fieldable blocks. The core module's code has a different purpose: Allowing modules to expose their blocks in a way they can be spawned more than once. Thus, you can create more than one instance of the "User menu" or "Navigation" blocks, and configure them differently. This also allows modules like Dashboard to spawn block instances for their own use on the Dashboard only.

This functionality was originally extracted and derived from @JohnAlbin's excellent menu_block module. Block API's API and hooks are closely following the existing ones of Block module in core. It's actually very simple to convert existing blocks for this improved API. The goal would be to move this API into core.

Bean == "Block Entities Aren't Nodes"

It's a play off of modules that turn blocks into nodes.

There is some design discussion here: #1160056: Make Bean types exportable

I'm not sure how #1160056: Make Bean types exportable relates to block_api's core functionality I mentioned in #2 ?

Sorry sun, that was a bad place to send you after I reread it.

Our goals are really inline. We both want to provide a way to create block types, then create instances of the block types. You approached it from a modifying the current state while I approached it from a clean slate. My idea was to make the API first, then make the UI an implementation of the API. The plugins are how you create new block types. I chose making the blocks as content (hence entities) because of that's what they are becoming. This also gives us fields built in (but not needed for the blocks).

I turned the block into content. It has a separate home on the UI /block/add, it has separate permissions then the block types. Blocks types are bundles on blocks and are completely in code (except for the UI implementation which will be exportable). Not a huge array in code like features, but really in code. I chose the boxes plugin methodology of OO based plugins that will be replaced with the Plugin system that Larry is working on.

My goal was to make the block system how I would want it from a coding/framework perspective. After looking over you code, I see many places I need to add to my code (thanks!) to make it more inline with the current block system.

Cheers!
Neil

sub

I don't get it, neither Block API nor Bean work with Entity reference. What am I missing?
Basically I want whatever will be the closest to a future Drupal core implementation of an entity-based block.