First off, apologies for taking so long to reply, I've been on holiday for a few weeks. Hope this answers your questions: On 19 Aug 2005, at 02:04, drupal-cvs@drupal.org wrote:

User: MegaGrunt Branch: HEAD Date: Fri, 19 Aug 2005 00:04:08 +0000

Added files: /modules/publication publication.module publication.mysql readme.txt

Log message: Handles data, logic, and UI of publication(s).

Component module which provides service to other modules.

On 19 Aug 2005, at 07:45, Dries Buytaert wrote:

- This does mean what? I guess I'll have to read the readme.txt

I wanted to explain two things with this log message... 1) This is a 'component' module. A module which manages a certain task/service on behalf of other modules. It has no dependencies on any other modules, and can be called by any module that needs this particular service. Other examples of component modules in contrib: Actions, Forms, and Folksonomy 2) Purpose of publication.module Manages the content of a publication(s). Content is defined as a collection of terms, which can come from one or more categories. In future I'd like to expand the module to handle other ways of aggregating content, e.g. node specific selections. A publication can be any collection of content, for any purpose, e.g. web site section, email newsletter, PDF, RSS, screen reader -> VOIP, etc. See the project page: http://drupal.org/project/publication

(which should be README.txt really).

OK, I'll change that on all my commits.

- I'm afraid the subtle differences in your modules' names are somewhat confusing:

Purpose of the other component modules I committed: * Schedule module - manages schedules, i.e. various time settings. See the project page: http://drupal.org/project/schedule * subscribed module - ties users to publications/actions/whatever See the project page: http://drupal.org/project/subscribed * templates module Stores templates in the database, which are used by other modules, e.g. email templates, PDF templates, etc. Templates can be edited through the browser, and can use profile and site data. See the project page: http://drupal.org/project/templates

+ There is already a scheduleR module. How does your schedule module differ?

ScheduleR module publishes/unpublishes nodes at scheduled times. Schedule module allows any other module (including ScheduleR) to manage schedules for any purpose, e.g. auto publishing a PDF, deleting nodes from a demo site, sending email, publishing/unpublishing nodes. In other words, ScheduleR is single purpose, Schedule is generic enough to be leveraged by any other module.

+ There is already a subscription module. How does your subscribe module differ?

There are actually 4 subscription related modules in contrib cvs, plus others like notify.module with similar functionality. This is why I'm so keen on component modules - most of the functionality of these modules is the same, the common tasks could be handled by 1 subscription component, leaving developers to concentrate on the unique features of their module. Current situation is that each of the developers of these modules is spending time creating and maintaining much the same set of functionality as the others.

Doesn't JonBob have a subscribe module too?

Yes, I talked to JonBob about merging the two modules. While we both like the idea, our projects where too much of a moving target to attempt to do this. Once we get a stable release of both modules I'd be interested in merging the two.

(I want a subscription.module in core (e-mail notifications) but don't want to ship both a subscribe and subscription module. I want a single-file module with or without additional .inc files.)

If I understand correctly, you want users to be able to subscribe to scheduled email notification of new content (nodes and comments). The component modules I committed perform most of the necessary tasks for this already, but not comment subscription (yet!).

- What other modules are going to re-use the scheduler and subscribe modules?

The eNewsletter module and Announcement module use the component modules I committed. http://drupal.org/project/enewsletter http://drupal.org/project/announcement Plus others in the pipeline....

- The e-commerce module groups its modules in modules/ecommerce. In general I like that better, because it makes for one well-defined project.

If they were for use only by enewsletter module, it would indeed make sense to collect them in modules/ecommerce - but as the whole point is to use them for a wide variety of other modules, and each component module is independent of the others, it made more sense to give each one their own directory. What would be better of course would be to create a separate cvs directory for components ;-) Best regards, Robert Castelo [MegaGrunt]