Mail Merge Specification: Technological Req'mts

WORK IN PROGRESS

THIS PAGE IS WORK IN PROGRESS!

NOTE: Please refer to the Terminology for the exact definition of words and phrases!

Selection of Technology

Investigations into technologies that will be needed for supporting the key features of the implementation of Mail Merge in OpenPetra are to be undertaken.

Technology: Definition

With the term 'technology' we mean in this specific context a solution for the implementation of Mail Merge in OpenPetra which provides the Key Features of the Mail Merge implementation (perhaps minus the creation of the Mail Merge Data Set).

Technologies could be made up of...

• a single product that provides the solution
  • Example: word processor that can be automatically 'driven' by OpenPetra through some means to fulfil the requirements and that is capable of replacing Placeholders with data from the Mail Merge Data Set
• multiple products that work together to create the solution
  • Example: a WYSIWYG editor that can be used for the *creation and parameterisation of the Mail Merge Document* that is capable of saving the document in a way that can be read by a library/standalone executable that is capable of *producing the Merged Documents for the individual recipients out of the underlying Mail Merge Data Set*, perhaps with the help of OpenPetra-specific plug-ins that provide the *customisable control logic for the creation of the Mail Merge Data Set*.

A technology that will be suitable for the implementation of Mail Merge in OpenPetra will need provide features that make it possible to meet the required outcome.

Key Features

The key features that the technologies will need to provide are:

• the creation of the Mail Merge Document;
• the parametrisation of the Mail Merge Document through Placeholders and perhaps other means;
• the production of the Merged Documents for the individual recipients out of the underlying Mail Merge Data Set;
• support for all the output options by some means that should (preferably) be fully automatic.

Optional Features

The technologies could optionally also provide:

• Customisable control logic for the creation of the Mail Merge Data Set
  • the customisable control logic could be programmed either
    • in a programming or definition language that the technology supports and that will be capable of working with data that is passed either in memory (e.g. using an in-memory XML representation, e.g. .Net's XmlDocument or a serialized form of it; using a .NET-serialized ADO.NET DataSet) or some temporary file (in-memory-passing preferred over temporary file).
      • that is so that the OpenPetra DB doesn't need to be queried directly from that technology as we want to have the capabilities of OpenPetra's powerful RDBMS Abstraction Layer retained! (OpenPetra would get the required data out of the RDBMS and pass it on to the technology in a suitable format.)
    • with the help of OpenPetra-specific plug-ins, preferably written in C#.
• other supporting means for the creation of the Mail Merge Data Set

Mail Merge Technology: Client Side or Server Side

• Technologies for implementing the Key Features apart from the *creation of the Mail Merge Document* could be client-based or server-based.
  • Entirely server-based would be preferred because this
    • would enable the execution of a Mail Merge Run also from a web interface (no client would be run on a Windows or Linux workstation in that case!)
    • would also mean that the Mail Merge Data Set would not need to be transferred from server to client (the client could be on a remote connection [i.e. not in the same network than the server, possibly through the Internet] and for large Mail Merge Data Sets the need for the data transfer of the Mail Merge Data Set from server to client could be slowing down the mail Merge Run significantly).
• Client and server could be both run on Windows or Linux, hence the technologies should support that, if possible.

Likely Candidates for Technologies That Should be Investigated

• Microsoft.Office.Interop.Word Library
  • .NET Interop Wrapper libraries supplied by MS for MS Word Automation through COM
    • Proprietary and Windows-OS / COM based: If those libraries are used then the technology would be restricted to the Windows Operating System (whether the technology would be used client or server side) - which is not that desirable.
    • However, if no other technology can be found that could provide what we need then this restriction would be acceptable, BUT in that case it must be ensured - to the maximum extend possible - that the implementation of Mail Merge in OpenPetra could be changed to another technology later with as little change as possible (i.e. a major re-write would not be acceptable!).
• Possibly: standalone native .NET implementation for support of the MS Word Format (doc/docx).
  • Requirement: GPL-compatible Open Source licence, or at least Freeware
• AODL .NET Library
  • standalone native .NET implementation for support of the OpenOffice/LibreOffice OpenDocument Format.
  • Requirement: GPL-compatible Open Source licence (haven't checked Licence yet!)
  • it would be good if OpenOffice/LibreOffice Writer wouldn't need to be installed!
  • it would be great if it would work with mono for the execution on Linux, but this is not required (Windows is the minimum, though!)
• Possibly: different standalone native .NET implementation for support of the OpenOffice/LibreOffice OpenDocument Format
  • Requirement: GPL-compatible Open Source licence, or at least Freeware
  • it would be good if OpenOffice/LibreOffice Writer wouldn't need to be installed!
  • it would be great if it would work with mono for the execution on Linux, but this is not required (Windows is the minimum, though!)
• Possibly: standalone WYSIWYG Editor that allows use of Placeholders
  • Requirement: GPL-compatible Open Source licence, or at least Freeware
  • it would be great if would work on both Windows and Linux Operating System, but this is not required (Windows is the minimum, though!)
• Possibly: standalone native .NET libraries or standalone executable that allow replacement of Placeholders in Mail Merge Documents with data from a Mail Merge Data Set
  • Requirement: GPL-compatible Open Source licence, or at least Freeware
  • it would be great if *standalone native .NET libraries* would work with mono for the execution on Linux, but this is not required (Windows is the minimum, though!)
  • it would be great if *standalone executables* would work on both Windows and Linux Operating System, but this not required (Windows is the minimum, though!)
• Possibly: standalone software (not a word processor) that is purpose-written for performing Mail Merge and that is capable of meeting the Key Points
  • Requirement: GPL-compatible Open Source licence, or at least Freeware
  • it would be great if would work on both Windows and Linux Operating System would be nice, but this not required (Windows is the minimum, though!)
• TODO
  • (To be extended by MarkP if he finds some other likely candidate)

Base Technologies that Should be Avoided

• Anything that requires Java to be installed on either Client or Server.
  • Reason: We use solely .NET for OpenPetra and don't want to introduce a dependency on a different technology platform.