Here's some thoughts as I formulate a wish-list to try and explain how I want to use this module.
Most here is mostly possible within the current version of enewsletter, but I need something a little more, with reference towards 'epublish' (which I don't like as much, but is in the same family of modules)

There can be at least 4 different types of mailout/newsletter/publication to my mind,
There is a lot of commonality, but also a few features each current implimentation lacks.
I believe that with a bit of work, options can be made to extend the current code in this direction.

The different flavours are as follows (forgive me if I missed or over-simplified a few features):

Announcement

A one-off mailout to all subscribed users.
All content is written once by the editor,
wrapped in a formatting template,
mailed to everyone on the mailing list,
and that's it.

eNewsletter

An eNewsletter (classic) is a bit like an automated newsfeed.
It's a mostly automatic collection of news stories recently posted to the originating site.
All stories meeting certain criteria are collected as 'teasers'
into a mailout that is formatted and posted out at defined intervals.
This method is effective as a 'digest' of activity on the site, but has less of a personal tone.

Nodes (stories) become published in the newsletter mainly due to whether they participate in defined taxonomy terms.

eMailout

The eMailout is a cross between the Announcement and the eNewsletter.
A 'eMailout' definition has a format and subscriber list of its own, like both the above, but it is comprised of sequential hand-crafted 'issues'.
Each issue consists primarily of an editorial introduction (like a one-off 'announcement')
but may also contain a few selected news teasers like the eNewsletter.

The eMailout can be edited, saved, proofed and reviewed prior to publication, giving it a publishing workflow
like all other content nodes.
An eMailout, when published (mailed to all subscribers),
also becomes a page archived on the site proper. This permanence is lacking from both the first two variations, as the Announcement is too trivial and lightweight,
and the eNewsletter is just a time-sensitive collation of active stories with no front, editorial or overview page.

The eMailout however, is consciously put together by an editor as a deliberate unit.
The story nodes are chosen and ordered by the editor, and content is written specifically in reference to 'this issue'.

ePublish

The ePublish method, (supplied by epublish.module), has no specific 'mailout' capability.
it exists to

organize a group of postings into a publication, such as a newspaper, magazine or newsletter.

by grouping different pages on the server as being part of a specific issue release.

Following the newspaper model, each 'edition' may have a collection of stories or columns, all sharing the same or similar release date.
Each edition can have subsections within it, to allow for broad, taxonomy-defined categories.

Stories are selected for the editions largely automatically, based on timespan, node type and taxonomy matches. The editor can then refine which page is part of the issue or not.

Through all this , the concept of an epublish 'issue' is just a grouping mechanism to collect different pages already published on the server.
There is (AFAIK) no 'front page' or editorial introduction to define each edition,
and there is no mailout capacity.

Soo...

Obviously my speculated 'eMailout' (I don't actually like that name) is the missing link in this list, and it's this that I'd like to work on/towards.

Robert has suggested I enumerate the requirements as individual 'feature requests', and I'll try to do so in this group now, but I think one radical requirement will be for the creation of an 'issue' type node to support the editing and proofing of an 'issue' structure as well as the eventual site-publishing of it. I'm currently comparing the schemas in the above-mentioned 'ePublish module, but I haven't found much I like yet.

.dan.

Comments

robert castelo’s picture

Status: Active » Closed (won't fix)

This is better suited to a forum discussion, marking it as 'won't fix'

robert castelo’s picture

Status: Closed (won't fix) » Closed (fixed)