Re: Wanted:MAIL.MAI structure definition

On Tue, 06 Jun 2006 16:44:00 -0700, Hoff Hoffman <hoff-remove-this@xxxxxx> wrote:

Tom Linden wrote:

As I said, it was just curiosity. If there is not a compelling reason to
keep something proprietary, then starlet it. There, I created a new verb.

I'd flip that over. If there's not a compelling reason to share a particular interface -- to render the interface public, or at least to allow some sort of sharing -- then keep the interface private.

Opening any arbitrary interface runs contrary to the typical opacity of the internal interfaces and of application modularity and of long-standing programming practices. And it makes the usual and expected application compatibility far more difficult to achieve and to maintain.

If I had the cycles to re-implement MAIL all over again, for instance, we'd be using XML and/or a relational database, and some of these pieces would be (far) more visible. But opening up traditional internal APIs or database file organizations to visibility obviously invites folks to use the APIs, and this is access is most definitely a two-edged sword. With XML or a relational database -- or a way to export to same -- maintaining compatibility is easier, and defending against corruptions -- whether in the code, or in something that a programmer has hooked into the interface -- is easier.

There have been changes to the naming of various MAIL files over the years, for instance, and there are definite limits to the current MAIL design. If we open the database API, we effectively codify the current design in concrete, and make it far harder (if not impossible) to re-work these interfaces and these designs compatibly.

If there are particular requirements not met within the existing interface(s), then these should be addressed through callable MAIL or similar extensions. Opening up the internals of an arbitrary hunk of code serves no purpose, and (in my experience) tends to cause problems for everybody involved. I've ported code, for instance, that expected modifications directly to the underlying operating system in support of the application code -- kernel patches. Shudder.

I see the merit to your arguments. I am not convinced that XML is a step
forward. I have looked at embedding an XML parser in PL/I as IBM has done
and is used as part of their Websphere package. Personally, I don't think
anyone should have to write XML, if you need to use it as an interface then
let's develop tools to generated it. If I have understood correctly, mail
is organised as an ISAM file. Such files are eminently more efficient than
relation DBs.

.

Relevant Pages

  • Re: variable length fields for flexibility in subroutines
    ... What you might look into is creating a description of your "interface ... block" in XML, then parsing that document and spinning through the nodes ... existing system (no recompilation of any Assemblies), is efficient, and ... Interface blocks for inter-program communication...Create an Interface ...
    (comp.lang.cobol)
  • Re: developing for something that isnt there..
    ... xml was chosen becouse well. ... creating a tree model of javabeans was my insisting becouse i didnt' ... had a complelty differnt strucutre and style of interface, ... and interface to send messages about them the classes ...
    (comp.lang.java.programmer)
  • Re: Wanted:MAIL.MAI structure definition
    ... If there's not a compelling reason to share a particular interface -- to render the interface public, or at least to allow some sort of sharing -- then keep the interface private. ... If I had the cycles to re-implement MAIL all over again, for instance, we'd be using XML and/or a relational database, and some of these pieces would be more visible. ... But opening up traditional internal APIs or database file organizations to visibility obviously invites folks to use the APIs, and this is access is most definitely a two-edged sword. ... If we open the database API, we effectively codify the current design in concrete, and make it far harder to re-work these interfaces and these designs compatibly. ...
    (comp.os.vms)
  • Re: problems typecast,find by function/member name and getting "managed reference"
    ... and then call methods in the interface. ... and add info about it in XML resource list file and designers who via ... *compiler* more information, which clearly isn't relevant at runtime. ... Casting is not relevant if some datais unmodified(in ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: developing for something that isnt there..
    ... i've been taksed to create a framework that would read a complex xml ... problem that java bean tree has not been built yet. ... i do have a concept of what to pull from the xml, ... and interface to send messages about them the classes ...
    (comp.lang.java.programmer)