merge newsletter module, inspect adopt to 7.x-2.x

Some things to share with you, before starting getting a deeper look in current simplenews situation (advices, mistakes i made, opinions):

Depend on Entity API module.It seriously makes everything easier, especially with its wrappers, and gives you away a lot of stuff for free..rules integration, exportables etc etc...We wanted to avoid one more dependency in newsletter module and in the end, i just ended up wasting more of my time:/

Turn everything into fields..I know this makes databases huge, but seriously, it gives the end user far more greater flexibility, on both display and management, it gives us views integration for free and generally..less feature requests:)

Dont make hardcoded assumptions on what the user needs to send as newsletters...it can be anything..better to not make any assumptions in the core module installation and let then user decide which addon modules to enable..lets say eg.. taxonomy simplenews (based and depended on taxonomy) or views simplenews (depended on views) and then create the necessary fields if needed.
I started newsletter module, with a dependency on taxonomy and based everything on it.Well this made it harder for me to let non taxonomy-depended content get into my newsletters and a lot of manual work.

Lastly...Use Entityreference module! i never regret this decision..it is also a module with a lot of future, and we definitely gonna use this in drupal 8...(we get roles as entities : role based newsletter just got easier!)

Yes, as Miro said, the patch over there contains all of your suggestions already except not being node specifc . It does remove a lot of node specific stuff, but it's going to take a while until all can be removed, if at all.

Great! i read #1309404: Convert Newsletter categories to custom entity and i agree to most of the point made there!

To send even other stuff (non-nodes, entity reference) it seems a bit more to do i think. I wouldn't expect we're going down that road very soon.
Will you find some time to help us pushing this direction?

So..let me get this straight:

For 7.x-2.x:
dont we plan on getting more entities? or the only thing that changes is just the newsletter categories?
Subscribers is definitely something else that should be converted to entities...even make them a bundle of user entity:) Then...the newsletters..should stop being nodes:)
And i am also checking whether we actually need Newsletter Categories..

The above should be the first things to be done in 7.x-2.x branch and alter the architecture a bit to be more flexible..i know there a lot of things to be done but i can push it:)
Else i will spend my tme, refactoring some of newsletter module to depend on Entity API , getting rid of taxonomy hardcore assumptions and maybe stealing simplenews spooling system hehe:)
Seriously i just think, that if we want to build a really cool newsletter system, flexible and easily configured, we should take the path of drupal commerce and we are already late, if we want to have this ready before drupal 8

The first step for 7.x-2.x is the above issue, you're welcome to work on it. We're probably not getting back to that until there is a stable version of 7.x-1.x (which is delayed due to ...complications). One thing that is done in that issue is a major naming cleanup, categories become newsletters, the nodes that are sent are issues.

Subscribers will be converted into an entity as well, that should actually be much simpler because they already are a separate table. Making them a user bundle is not an empty, simply because user.module does not support bundles. Not sure what to do with the subscriptions yet, maybe make them an entity as well. They aren't just a reference.

Removing explicit dependencies on nodes is a goal, so that different things can be be sent. However, I don't see us introducing a new issue entity, we'd still use and focus on nodes. At least in 7.x, nodes are still the main piece of content and many modules still only integrate properly with nodes.

Suggestion:
What today are 'newsletter categories', be it based on taxonomy or entity bundles, could be achieved with views? The newsletter category list at the newsletter creation can be a handful of simplenews-enabled views.
This would enable dynamic newsletter lists such as 'people living in [field:city]' or 'people not logged since [x]'. This way, it's up to the site builder which fields/taxonomies/whatever use to fill newsletter lists.
Possible advantages are better/easier language support(?), more flexible categorizations, dynamic lists, etc.
And for 8.x, now that views is in core, it would make more sense and hopefully make code easier to maintain.
My 2c.

Hi Miro.
I think I've failed to explain what I was meaning.
My idea was not about populating newsletter issues content with views.
It was about populating the newsletter issue **recipient list** from views.
What now are static lists of subscribers for each category could be the result of running different views. You would be able to create as many views as needed and later send issues to subscribers matching some view criteria.
I'm not sure how swapping the simplenews categories by a list of simplenews-enabled views would affect. Maybe it would be better as an addition to static categories. I'm unsure if the views-populated recipient lists would be a complete replacement of current categories.

#1547642: [meta] SimpleNews and the Party CRM has my thoughts on dynamic newsletter lists, it's not relevant to this issue as newsletter.module doesn't support this either ;)

Will follow that issue. Looks like to me that it's a good candidate for a Simplenews contrib module when the time to explore that path comes. Thanks for the feedback.