Has anyone (*seriously*) suggested it and tried to implement?
--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
The difference between reality and unreality is that reality has so
little to recommend it.
-- Allan Sherman
Andrzej Adam Filip wrote:
> Has anyone (*seriously*) suggested it and tried to implement?
Aieeee.... I hope not. Why would you want to do that??
I can think of only one plausible reason (to allow GUI configuration tools
generate a sendmail.cf) and I don't think that's a good enough reason
to make XML the source format.
Regards,
David.
David F. Skoll wrote:
> Andrzej Adam Filip wrote:
>
>> Has anyone (*seriously*) suggested it and tried to implement?
>
> Aieeee.... I hope not. Why would you want to do that??
>
> I can think of only one plausible reason (to allow GUI configuration tools
> generate a sendmail.cf) and I don't think that's a good enough reason
> to make XML the source format.
Linuxconfig should have a sendmail configuration module without any use
of xml.
--
//Aho
"David F. Skoll"
> Andrzej Adam Filip wrote:
>
>> Has anyone (*seriously*) suggested it and tried to implement?
>
> Aieeee.... I hope not. Why would you want to do that??
to allow:
* much more options for FEATUREs and MAILERs
* named options for FEATUREs and MAILERs
* easier creation of "almost like" MAILERs
* keeping the documentation in the same file
* to ease and encourage more "code donations" by using standard more
generally used and simpler than m4
To be frank the current *STYLE* of m4 files makes part of them hard to
read and understand. With *cleaner* "coding style" of sendmail's m4
files my "eagerness" to migrate would be smaller.
> I can think of only one plausible reason (to allow GUI configuration tools
> generate a sendmail.cf) and I don't think that's a good enough reason
> to make XML the source format.
I have been thinking about two stage migration:
1) generate mailer and feature m4 files from xml
2) get rid of m4 files completely
--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Oh yeah. Forgot about those. Getting senile, I guess...
-- Larry Wall in <199710261551.HAA17791@wall.org>
On Apr 14, 10:30 pm, Andrzej Adam Filip
> "David F. Skoll"
> > Andrzej Adam Filip wrote:
> >> Has anyone (*seriously*) suggested it and tried to implement?
> > Aieeee.... I hope not. Why would you want to do that??
Because they can - but is it a good idea? I wonder.
> to allow:
> * much more options for FEATUREs and MAILERs
> * named options for FEATUREs and MAILERs
> * easier creation of "almost like" MAILERs
How many MAILERS do we need really?
> * keeping the documentation in the same file
> * to ease and encourage more "code donations" by using standard more
> generally used and simpler than m4
> To be frank the current *STYLE* of m4 files makes part of them hard to
> read and understand. With *cleaner* "coding style" of sendmail's m4
> files my "eagerness" to migrate would be smaller.
>
> > I can think of only one plausible reason (to allow GUI configuration tools
> > generate a sendmail.cf) and I don't think that's a good enough reason
> > to make XML the source format.
>
> I have been thinking about two stage migration:
> 1) generate mailer and feature m4 files from xml
> 2) get rid of m4 files completely
Wouldnt that be nice.. But there has got to be a better way than xml/
xsl: <
SOAP, AJAX, whats next? Im getting dish pan hands here : >
Ive thought about this issue before. Perhaps we should let sleeping
dogs lie
is what I concluded. But by all means have at it - but Im not eager to
ramp up
to yet another hip language/paradigm of the day. Im still in Object
Oriented
recovery mode : <
usenetpersongerryt@gmail.com wrote:
> On Apr 14, 10:30 pm, Andrzej Adam Filip
>> "David F. Skoll"
>> > Andrzej Adam Filip wrote:
>> >> Has anyone (*seriously*) suggested it and tried to implement?
>> > Aieeee.... I hope not. Why would you want to do that??
>
> Because they can - but is it a good idea? I wonder.
>
>> to allow:
>> * much more options for FEATUREs and MAILERs
>> * named options for FEATUREs and MAILERs
>> * easier creation of "almost like" MAILERs
>
> How many MAILERS do we need really?
In *typical* installation? *NONE* (or hardly any)
I have always heard that sendmail advantage is its high configurability.
I have also heard that people preferring simplicity choose postfix/exim.
So feel free to point out what is supposed to make sendmail-8 better
than other *free* alternatives e.g. exim, postfix [alphabetical order].
>> * keeping the documentation in the same file
>> * to ease and encourage more "code donations" by using standard more
>> generally used and simpler than m4
>> To be frank the current *STYLE* of m4 files makes part of them hard to
>> read and understand. With *cleaner* "coding style" of sendmail's m4
>> files my "eagerness" to migrate would be smaller.
>>
>> > I can think of only one plausible reason (to allow GUI configuration tools
>> > generate a sendmail.cf) and I don't think that's a good enough reason
>> > to make XML the source format.
>>
>> I have been thinking about two stage migration:
>> 1) generate mailer and feature m4 files from xml
>> 2) get rid of m4 files completely
>
> Wouldnt that be nice.. But there has got to be a better way than xml/
> xsl: < SOAP, AJAX, whats next? Im getting dish pan hands here : > Ive
> thought about this issue before. Perhaps we should let sleeping dogs
> lie is what I concluded. But by all means have at it - but Im not
> eager to ramp up to yet another hip language/paradigm of the day. Im
> still in Object Oriented recovery mode : <
We can implement step "1" as an option and decide after that what to do
next [ the decision point *after* seeing some real life results ].
I dislike to *waste* (my own) time creating something destined to rotten
due to lack of maintenance *team* just like HTMLized cf/README at
http://www.sendmail.org/m4/readme.html *frozen* at sendmail-8.12.11.
--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
For the run-time caching, I was going to suggest "cached" (doh!), but
perhaps "once" is more meaningful to ordinary people.
-- Larry Wall in <199709021812.LAA12571@wall.org>
On Apr 15, 10:40 am, Andrzej Adam Filip
> usenetpersonger...@gmail.com wrote:
> > On Apr 14, 10:30 pm, Andrzej Adam Filip
> >> "David F. Skoll"
> >> > Andrzej Adam Filip wrote:
> >> >> Has anyone (*seriously*) suggested it and tried to implement?
> >> > Aieeee.... I hope not. Why would you want to do that??
> > Because they can - but is it a good idea? I wonder.
> >> to allow:
> >> * much more options for FEATUREs and MAILERs
> >> * named options for FEATUREs and MAILERs
> >> * easier creation of "almost like" MAILERs
> > How many MAILERS do we need really?
> In *typical* installation? *NONE* (or hardly any)
But for faxes and stuff we do..
> I have always heard that sendmail advantage is its high configurability.
> I have also heard that people preferring simplicity choose postfix/exim.
> So feel free to point out what is supposed to make sendmail-8 better
> than other *free* alternatives e.g. exim, postfix [alphabetical order].
> >> * keeping the documentation in the same file
> >> * to ease and encourage more "code donations" by using standard more
> >> generally used and simpler than m4
> >> To be frank the current *STYLE* of m4 files makes part of them hard to
> >> read and understand. With *cleaner* "coding style" of sendmail's m4
> >> files my "eagerness" to migrate would be smaller.
> >> > I can think of only one plausible reason (to allow GUI configuration tools
> >> > generate a sendmail.cf) and I don't think that's a good enough reason
> >> > to make XML the source format.
> >> I have been thinking about two stage migration:
> >> 1) generate mailer and feature m4 files from xml
> >> 2) get rid of m4 files completely
> > Wouldnt that be nice.. But there has got to be a better way than xml/
> > xsl: < SOAP, AJAX, whats next? Im getting dish pan hands here : > Ive
> > thought about this issue before. Perhaps we should let sleeping dogs
> > lie is what I concluded. But by all means have at it - but Im not
> > eager to ramp up to yet another hip language/paradigm of the day. Im
> > still in Object Oriented recovery mode : <
> We can implement step "1" as an option and decide after that what to do
> next [ the decision point *after* seeing some real life results ].
You can : > XML has put me off since day one. Maybe I should be less
rigid : <
> I dislike to *waste* (my own) time creating something destined to rotten
> due to lack of maintenance *team* just like HTMLized cf/README athttp://www.sendmail.org/m4/readme.html*frozen* at sendmail-8.12.11.
I concur. Even if things were up to date its still a bit
"disorganized".
Yes I agree that something should be 'done' about sendmail...
Easier configs would be great. Striping out legacy code would be good
too.
Or cleaning it up. So many ifdefs : >
Claus is busy elsewhere - and since he's moved on things feel a bit
stale.
You know the history. Sendmail X - a total re-write that went nowhere.
Pity.
So here we are.
usenetpersongerryt@gmail.com wrote:
> On Apr 15, 10:40 am, Andrzej Adam Filip
>> usenetpersonger...@gmail.com wrote:
>> > On Apr 14, 10:30 pm, Andrzej Adam Filip
>> >> "David F. Skoll"
>> >> > Andrzej Adam Filip wrote:
>> >> >> Has anyone (*seriously*) suggested it and tried to implement?
>> >> > Aieeee.... I hope not. Why would you want to do that??
>> > Because they can - but is it a good idea? I wonder.
>> >> to allow:
>> >> * much more options for FEATUREs and MAILERs
>> >> * named options for FEATUREs and MAILERs
>> >> * easier creation of "almost like" MAILERs
>> > How many MAILERS do we need really?
>> In *typical* installation? *NONE* (or hardly any)
>
> But for faxes and stuff we do..
1) There is a fax mailer present.
cf/mailer/fax.m4
#v+
# Tested with HylaFAX 4.0pl1
[...]
VERSIONID(`$Id: fax.m4,v 8.16 2001/11/12 23:11:34 ca Exp $')
v-
2) AFAIR sendmail in m4 file provided by sendmail.org *does not*
support FAX email addresses as recommended by RFC2304
from year 1998.
Some examples of minimal RFC2304 "fax-email" addresses:
FAX=+3940226338@faxworld.org
FAX=+12027653000/T33S=1387@faxworld.org
/FAX=+33-1-88335215/@faxworld.org
>> I have always heard that sendmail advantage is its high configurability.
>> I have also heard that people preferring simplicity choose postfix/exim.
>> So feel free to point out what is supposed to make sendmail-8 better
>> than other *free* alternatives e.g. exim, postfix [alphabetical order].
> [...]
--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
A feature is nothing more than a bug with seniority.
-- Unknown source
Post removed (X-No-Archive: yes)
On Apr 15, 1:38 pm, Andrzej Adam Filip
> usenetpersonger...@gmail.com wrote:
> > On Apr 15, 10:40 am, Andrzej Adam Filip
> >> usenetpersonger...@gmail.com wrote:
> >> > On Apr 14, 10:30 pm, Andrzej Adam Filip
> >> >> "David F. Skoll"
> >> >> > Andrzej Adam Filip wrote:
> >> >> >> Has anyone (*seriously*) suggested it and tried to implement?
> >> >> > Aieeee.... I hope not. Why would you want to do that??
> >> > Because they can - but is it a good idea? I wonder.
> >> >> to allow:
> >> >> * much more options for FEATUREs and MAILERs
> >> >> * named options for FEATUREs and MAILERs
> >> >> * easier creation of "almost like" MAILERs
> >> > How many MAILERS do we need really?
> >> In *typical* installation? *NONE* (or hardly any)
> > But for faxes and stuff we do..
> 1) There is a fax mailer present.
> cf/mailer/fax.m4
> #v+
> # Tested with HylaFAX 4.0pl1
> [...]
> VERSIONID(`$Id: fax.m4,v 8.16 2001/11/12 23:11:34 ca Exp $')
> v-
> 2) AFAIR sendmail in m4 file provided by sendmail.org *does not*
> support FAX email addresses as recommended by RFC2304
> from year 1998.
> Some examples of minimal RFC2304 "fax-email" addresses:
> FAX=+3940226...@faxworld.org
> FAX=+12027653000/T33S=1...@faxworld.org
> /FAX=+33-1-883352...@faxworld.org
I knew about the fax mailer - not that its insufficient or non RFC
compliant : >
Someone else posts that m4 is just fine. I think they are a majority
of one though.
Anyway thats what sendmail understands for now.
If your idea proves out then others will join in...
Ralf Döblitz
> Andrzej Adam Filip
> [...]
>> So feel free to point out what is supposed to make sendmail-8 better
>> than other *free* alternatives e.g. exim, postfix [alphabetical order].
>
> The use of an established, well known and sufficiently versdatile macro
> processor, namely m4. Yes, I use it also for webserver configuration and
> lots of other typical system administration issues.
So *you* no *sufficiently* good reason to change "the current state".
I disagree. "The silence" makes *your* opinion stronger.
--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Love is a snowmobile racing across the tundra, which suddenly flips
over, pinning you underneath. At night the ice weasels come.
-- Matt Groening, "Love is Hell"
usenetpersongerryt@gmail.com wrote:
> On Apr 15, 1:38 pm, Andrzej Adam Filip
>> usenetpersonger...@gmail.com wrote:
>> > On Apr 15, 10:40 am, Andrzej Adam Filip
>> >> usenetpersonger...@gmail.com wrote:
>> >> > On Apr 14, 10:30 pm, Andrzej Adam Filip
>> >> >> "David F. Skoll"
>> >> >> > Andrzej Adam Filip wrote:
>> >> >> >> Has anyone (*seriously*) suggested it and tried to implement?
>> >> >> > Aieeee.... I hope not. Why would you want to do that??
>> >> > Because they can - but is it a good idea? I wonder.
>> >> >> to allow:
>> >> >> * much more options for FEATUREs and MAILERs
>> >> >> * named options for FEATUREs and MAILERs
>> >> >> * easier creation of "almost like" MAILERs
>> >> > How many MAILERS do we need really?
>> >> In *typical* installation? *NONE* (or hardly any)
>> > But for faxes and stuff we do..
>> 1) There is a fax mailer present.
>> cf/mailer/fax.m4
>> #v+
>> # Tested with HylaFAX 4.0pl1
>> [...]
>> VERSIONID(`$Id: fax.m4,v 8.16 2001/11/12 23:11:34 ca Exp $')
>> v-
>> 2) AFAIR sendmail in m4 file provided by sendmail.org *does not*
>> support FAX email addresses as recommended by RFC2304
>> from year 1998.
>> Some examples of minimal RFC2304 "fax-email" addresses:
>> FAX=+3940226...@faxworld.org
>> FAX=+12027653000/T33S=1...@faxworld.org
>> /FAX=+33-1-883352...@faxworld.org
>
> I knew about the fax mailer - not that its insufficient or non RFC
> compliant : >
> Someone else posts that m4 is just fine. I think they are a majority
> of one though.
> Anyway thats what sendmail understands for now.
> If your idea proves out then others will join in...
Have you ever heard polish saying:
"A piece of *WONDERFUL* job needed by nobody"? :-)
*Successful* open source project needs *TEAM* work *FAST*.
--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
If what they've been doing hasn't solved the problem, tell them to
do something else.
-- Gerald Weinberg, "The Secrets of Consulting"
Andrzej Adam Filip wrote:
> "David F. Skoll"
[Regarding XML config file for Sendmail]
>> Aieeee.... I hope not. Why would you want to do that??
> to allow:
> * much more options for FEATUREs and MAILERs
> * named options for FEATUREs and MAILERs
> * easier creation of "almost like" MAILERs
> * keeping the documentation in the same file
> * to ease and encourage more "code donations" by using standard more
> generally used and simpler than m4
I don't see why you would choose XML for this. XML was originally
designed as a data-interchange language. Using it for configuration
files is a bit of an abuse; it leads to seriously ugly configuration
files. And if you are validating the XML (as you should be), it makes
*writing* configuration files by hand a complete nightmare.
If you want something nice and simple, you could probably do everything
you need with an INI-style configuration file with sections and simple
var=value statements.
> To be frank the current *STYLE* of m4 files makes part of them hard to
> read and understand. With *cleaner* "coding style" of sendmail's m4
> files my "eagerness" to migrate would be smaller.
No, it's just that Sendmail is an old piece of software with a
bizarre/idiosyncratic configuration language that's very difficult to
hide under a layer of syntactic sugar. And that's why I love it. :-)
XML is just the buzzword of the day. People who mention "XML" a lot
also tend to mention things like "Java" and "Enterprise", and I tend
not to travel in those circles (mostly because I actually need to get
stuff done.)
Regards,
David.
"David F. Skoll"
> Andrzej Adam Filip wrote:
>
>> "David F. Skoll"
>
> [Regarding XML config file for Sendmail]
>
>>> Aieeee.... I hope not. Why would you want to do that??
>
>> to allow:
>> * much more options for FEATUREs and MAILERs
>> * named options for FEATUREs and MAILERs
>> * easier creation of "almost like" MAILERs
>> * keeping the documentation in the same file
>> * to ease and encourage more "code donations" by using standard more
>> generally used and simpler than m4
>
> I don't see why you would choose XML for this. XML was originally
> designed as a data-interchange language. Using it for configuration
> files is a bit of an abuse; it leads to seriously ugly configuration
> files. And if you are validating the XML (as you should be), it makes
> *writing* configuration files by hand a complete nightmare.
>
> If you want something nice and simple, you could probably do everything
> you need with an INI-style configuration file with sections and simple
> var=value statements.
I have looked at the problem from perspective of using program to
convert one format into another.
[ Something like saying that mailer smtp-plain (never use ESMTP) is just
like mailer smtp with flag F=2 added. ]
I can see no problem whatsoever in adding INI-style to XML converter ;-)
>> To be frank the current *STYLE* of m4 files makes part of them hard to
>> read and understand. With *cleaner* "coding style" of sendmail's m4
>> files my "eagerness" to migrate would be smaller.
>
> No, it's just that Sendmail is an old piece of software with a
> bizarre/idiosyncratic configuration language that's very difficult to
> hide under a layer of syntactic sugar.
It does not mean we should never ever *try* another variant of
"syntactic sugar".
> And that's why I love it. :-)
>
> XML is just the buzzword of the day. People who mention "XML" a lot
> also tend to mention things like "Java" and "Enterprise", and I tend
> not to travel in those circles (mostly because I actually need to get
> stuff done.)
Just to give you one simple "hint":
AFAIR Debian sendmail package tries to get list of maps used by sendmail
*from sendmail.mc*.
--
[pl>en Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
To think contrary to one's era is heroism. But to speak against it is madness.
-- Eugene Ionesco
Andrzej Adam Filip wrote:
> Has anyone (*seriously*) suggested it and tried to implement?
I was seriously thinking about another way to _represent_ the rule
sets. I mean something that transliterates the easy-to-parse, but hard-
to-understand (for most people) syntax into some more understandable
and vice verse for the .cf file.
As others, I'm not sure that XML is superior than other conf-
mechanisms, but in order to lower the hurdle esp. for new users of
sendmail, it would be a good thing to have a simple-configuration-
selector, where you can combine the most common configurations into a
working m4 set, without to hassel about 'dnl's, left or right
apostrophes, order of settings etc.pp. I do not find the m4-syntax
intentionally.
ska
ska
> Andrzej Adam Filip wrote:
>> Has anyone (*seriously*) suggested it and tried to implement?
>
> I was seriously thinking about another way to _represent_ the rule
> sets. I mean something that transliterates the easy-to-parse, but hard-
> to-understand (for most people) syntax into some more understandable
> and vice verse for the .cf file.
There are two ways:
a) add some "linear programming" constructs to "R" lines
[requires incompatible changes in sendmail binaries]
b) generating sendmail.cf "(almost) as it is" from easier to understand
by humans form
IMHO m4 syntax (as present in current files) does not meat
"being easy for humans to read" criteria.
> As others, I'm not sure that XML is superior than other
> conf-mechanisms, but in order to lower the hurdle esp. for new users
> of sendmail, it would be a good thing to have a simple-configuration-
> selector, where you can combine the most common configurations into a
> working m4 set, without to hassel about 'dnl's, left or right
> apostrophes, order of settings etc.pp. I do not find the m4-syntax
> intentionally.
--
[pl>en Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Diplomacy is the art of saying "nice doggie" until you can find a rock.
-- Wynn Catlin
Post removed (X-No-Archive: yes)
(Ok, I was going to avoid this thread, but I'm going to jump in now.)
On 04/17/08 12:40, Henning Hucke wrote:
> uhmm. Honestly I don't know for what purpose XML originally was designed
> for but its name says that its just a (general) markup language. So if
> you can say "here comes a feature description" it's ok for me but ...
> (see "..." below)
It is my (mis)understanding that XML was meant to be a general markup
language for data inter-change between desperate systems. I.e. take
data in what ever proprietary format you use and export it out to
something that is very metadata descriptive about the data that is
contained there in.
I think XML achieves this goal fairly well. However I don't think that
this makes it good to store things in. Rail flat cars are great for
transporting things, but that does not mean I'm going to have a rail
yard just to store things in / on.
> That's something I don't agree with. For normal sendmail.mc files and
> even for some more complicated ones XML would IMHO be overkill since the
> XML declarations you would have to write would kind of suppress the
> actual configuration data meaning there would be more XML idioms than
> sendmail configuration data.
Keep in mind that the sendmail.mc file is really in a form of data
processing language. It could probably be said that the .mc file is
really raw data and / or instructions for the m4 processor. In such .mc
files are a form of programing / instruction code. Going down that line
of thinking would you program in XML? I know that I would not.
Also remember that the .mc file is really just one of *MANY* that are
combined together to generate the .cf file. I think a closer example
would be any language that can direct the language interpreter to
include data from another file as well as setting variables that are
used in said file(s). I admit that I'm not versed in XML (I actually
try to avoid it) but I'm not aware that XML has that type of feature set.
There are also ways with in the .mc file that you can pass what will be
raw text (rules) directly in to the .cf file.
> Also not agreed. It would be more handwork but you also get something
> for it. You cold for instance use standard XML tools to generate the
> configuration file. You _could_ use XML editors and a template to write
> the configuration file and/or you could - beside the XML correctness -
> check the file for some kind of completeness with XML standard tools.
I think you (unintentionally) blew by David's point, namely "writing
configuration files *by hand*" (note the infuses on _*BY HAND*_). You
jumped directly in to using configuration tools to do it for you.
> Think on - what was its name - "WebC" which is a system to write code
> and its documentation in one file. You run one tool and you get the
> source code fed into the compiler system and you run another tool and
> get the documentation fed into the TeX compiler.
Ok, how does WebC apply to Sendmail as you propose?
> ... why not compiling the XML file with a XSLT processor into a .mc file
> feeding it into m4? It would not be much different from compiling a
> language into byte code which is compiled from the JIT-VM into machine
> code. This way the people who like XML could test the usability without
> having the full complexity of a sendmail.cf file immediately and people
> like you and me could see whether or not XML configuration files for
> sendmail have remarkable advantages.
I see no reason why the people that want to go the XML route could not
come up with something to convert XML to .mc. I'm curious, how many
lines would an XML file for the basic stock config for generic-linux be
as it comes from Sendmail.org?
> Remember that nearly every new thing/stuff starts its life by people
> saying that there is no serious use for it. XML has its uses like m4 and
> TeX have their ones.
I'm sure people do say that (I'm too young to know first hand). However
I think what is better asked / answered is what advantages does the new
way provide over the old way? What are the pros and cons of each. As I
like to tell people that are wanting persuade me to use something new
"Show me how my way is wrong (with logic).".
> I certainly agree a lot of times with a lot of people not stating that
> this is the case. But here I have to state a clear
>
> me too! :-)
>
> meaning that I also meet a lot of this kind of "experts" and also don't
> (want to) join these circles because I want things to get done. :-)
There is nothing wrong with voicing your opinion so long as you back
your opinion with some evidence (one way or the other) if you want your
opinion to be taken for more than an opinion (which are like a-holes,
everyone has at least one).
Grant. . . .
Post removed (X-No-Archive: yes)
Post removed (X-No-Archive: yes)
Andrzej Adam Filip wrote:
> I have looked at the problem from perspective of using program to
> convert one format into another.
The ultimate output (I assume) will still be sendmail.cf. So I don't
see an advantage in using XML as an intermediate format.
> Just to give you one simple "hint":
> AFAIR Debian sendmail package tries to get list of maps used by sendmail
> *from sendmail.mc*.
The Debian sendmail package maintainer is crazy. I've had numerous
heated discussions with him about the absurd heap of
perl/shell/Makefile goop he has packaged around Sendmail, but in the
end we just agreed to disagree. :-)
However, you are right: Some kind of configuration file more easily
parsed by tools *other* than Sendmail would be quite nice. (Or maybe
add command-line options to sendmail to ask it to parse its config file
and output useful information on stdout.)
Regards,
David.
"David F. Skoll"
> Andrzej Adam Filip wrote:
>
>> I have looked at the problem from perspective of using program to
>> convert one format into another.
>
> The ultimate output (I assume) will still be sendmail.cf. So I don't
> see an advantage in using XML as an intermediate format.
Let me give MAILER file as an example:
With mailer file in XML the file may be used quite easily for *many*
purposes (using *standard* tools):
1) generating part of sendmail.cf file
2) generating the relevant part of cf/README file
[easing keeping documentation and "code" in sync]
3) generating "derivate" XML mailer definition
With mailer file (cf/mailer/*.m4) the file stops at goal "1"
As I wrote in other posts in the thread:
a) some tool may be used to convert formats more "inexperience user"
friendly into xml (and back) [e.g. *.ini files]
b) most likely in *initial* stages of "evolutionary transition" XML files
will be used for generating cf/mailer/*.m4 and cf/feature/*.m4 files.
I do not really care what format is going to be used instead of *.mc file.
I do care about *UGLY* format of cf/*/*.m4 files. It had been a *huge*
step forward from creating sendmail.cf directly but (IMHO) the time has
came to do *NEXT* step [which will not be done ;-) ].
>> Just to give you one simple "hint":
>> AFAIR Debian sendmail package tries to get list of maps used by sendmail
>> *from sendmail.mc*.
>
> The Debian sendmail package maintainer is crazy. I've had numerous
> heated discussions with him about the absurd heap of
> perl/shell/Makefile goop he has packaged around Sendmail, but in the
> end we just agreed to disagree. :-)
It had surprised me that that map list is not retrieved from *.cf file :-)
> However, you are right: Some kind of configuration file more easily
> parsed by tools *other* than Sendmail would be quite nice. (Or maybe
> add command-line options to sendmail to ask it to parse its config file
> and output useful information on stdout.)
Long time ago I suggested and option to make it produce "normalized"
sendmail.cf it parsed [ it had been in one of those "cf to mc" requests].
--
[pl>en Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
We fight only when there is no other choice.
We prefer the ways of peaceful contact.
-- Kirk, "Spectre of the Gun", stardate 4385.3
Grant Taylor
> [...]
> Also remember that the .mc file is really just one of *MANY* that are
> combined together to generate the .cf file. I think a closer example
> would be any language that can direct the language interpreter to
> include data from another file as well as setting variables that are
> used in said file(s). I admit that I'm not versed in XML (I actually
> try to avoid it) but I'm not aware that XML has that type of feature
> set.
Have you noticed "via xsl" in the subject? :-)
http://en.wikipedia.org/wiki/Extensible_Stylesheet_Language
xsl is an xml specially designed to describe transformation of XML
file(s) into XML/HTML/text. Most likely switching from m4 to xml would
require two chained xsl transformations to avoid *simple* migration.
> There are also ways with in the .mc file that you can pass what will
> be raw text (rules) directly in to the .cf file.
m4 technique used by sendmail restricts number of such
"insertion points" in sendmail.cf without using custom
rule sets (Local_*).
> [...]
--
[pl>en Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Tomorrow's computers some time next month.
-- DEC
On 04/17/08 15:20, Andrzej Adam Filip wrote:
> Have you noticed "via xsl" in the subject? :-)
> http://en.wikipedia.org/wiki/Extensible_Stylesheet_Language
Sort of. However like I said, I'm not that familiar with XML or XSL.
As such I was not aware of the fact that XSL could do some of what is
needed.
One concern that I do have (from skimming the cited article) is that you
can set variables in XSL but you can not change them once they are set.
I've seen instances where an included .mc file will set a value that
may be previously set to something else.
Grant. . . .
Grant Taylor
> On 04/17/08 15:20, Andrzej Adam Filip wrote:
>> Have you noticed "via xsl" in the subject? :-)
>> http://en.wikipedia.org/wiki/Extensible_Stylesheet_Language
>
> Sort of. However like I said, I'm not that familiar with XML or
> XSL. As such I was not aware of the fact that XSL could do some of
> what is needed.
>
> One concern that I do have (from skimming the cited article) is that
> you can set variables in XSL but you can not change them once they are
> set. I've seen instances where an included .mc file will set a value
> that may be previously set to something else.
XSL variables are used *internally* during transformation of input
document(s) into output document.
--
[pl>en Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
IN MY OPINION anyone interested in improving himself should not rule out
becoming pure energy.
-- Jack Handley, The New Mexican, 1988.
----
http://groups.google.com/groups?selm=d0jxsjba78.Gordon@todd. fsf.hobby-site.com
Andrzej Adam Filip
> I have looked at the problem from perspective of using program to
> convert one format into another.
> [ Something like saying that mailer smtp-plain (never use ESMTP) is just
> like mailer smtp with flag F=2 added. ]
>
> I can see no problem whatsoever in adding INI-style to XML converter ;-)
I think your point is: The .mc-files are 'strange' to the uninitiated.
Granted. But do one therefor really need a new Config-File-Style. I
dunno. But *if* you are planning something as a complete guide for
the newbie - something ling "selfhtml" would be handy.
It's sometimes a pain to check for mailer -> common options for
mailers -> specifics for *this* mailer, side-effects, and so on.
Even people used to sendmail might use this, as for myself if I
need some of the more esoteric features I find myself with the
Bat-Book and flipping pages forth and back using tons of papers as
Bookmarks and emulating hypertext on plain-old-paper.
Sometimes this is like the old paperpack adventures "you see three
doors, if you take the left read on on page
read on page
cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS
Clemens Zauner
> Andrzej Adam Filip
>> I have looked at the problem from perspective of using program to
>> convert one format into another.
>> [ Something like saying that mailer smtp-plain (never use ESMTP) is just
>> like mailer smtp with flag F=2 added. ]
>>
>> I can see no problem whatsoever in adding INI-style to XML converter ;-)
>
> I think your point is: The .mc-files are 'strange' to the uninitiated.
> Granted. But do one therefor really need a new Config-File-Style. I
> dunno. But *if* you are planning something as a complete guide for
> the newbie - something ling "selfhtml" would be handy.
> It's sometimes a pain to check for mailer -> common options for
> mailers -> specifics for *this* mailer, side-effects, and so on.
> Even people used to sendmail might use this, as for myself if I
> need some of the more esoteric features I find myself with the
> Bat-Book and flipping pages forth and back using tons of papers as
> Bookmarks and emulating hypertext on plain-old-paper.
>
> Sometimes this is like the old paperpack adventures "you see three
> doors, if you take the left read on on page
> read on page
*Properly* designed XML may be used (by yet another set of XSL scripts)
to generate automatically cross referenced documentation (in HTML too).
--
[pl>en Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
There is more simplicity in the man who eats caviar on impulse than in the
man who eats Grape-Nuts on principle.
-- G. K. Chesterton
----
http://groups.google.com/groups/profile?user=anfi@onet.eu
http://groups.google.com/groups?selm=gcoc39je78@james.fsf.ho bby-site.com