Two giant thank yous

Neven Has haski at sezampro.yu
Sat Nov 24 13:14:16 PST 2001


Hi,

On Sat, Nov 24, 2001 at 08:28:55AM -0000, cpb at log2.net wrote:
> Hi Neven, 
> 
> I am not sure how to post to the ALFS-discuss list and get this comment
> in the right place. I don't wish to subscribe. You can put this on the list
> if you want, but it is enough for me that I have sent it.

You can just post to alfs-discuss at linuxfromscratch.org. I'm CCing this
message to the list (sorry for full quoting, that is the reason), and hoping
that others, who possibly reply to it, will CC it to you. (Or are you using
digest mode or something? Judging from your text below you do seem to
follow the list).

> There is no need to reply to this message.

I think there is. :) There are a lot of good points and suggestions in here.

> This letter has five parts, the first and last are most important.
> 
> ----------------------------------------------------------------------
> Part One: A GIANT THANK YOU for writing nALFS, a wonderful program!
> 
> ----------------------------------------------------------------------

Heh, I'm glad you like it. :)

> Part Two: Possibly reinventing the wheel with <include>.
> 
> The ALFS-discuss thread about <include> is veering toward the reinvention
> of many wheels, such as:
> 
> 1) The (draft) XML Inclusions (XInclude) efforts:
>    http://www.w3.org/TR/xinclude
> 
> 2) The "Conditional Sections" facility of XML:
>    http://www.w3.org/TR/REC-xml#sec-condition-sect
> 
> 3) Picking elements out of an existing XML document is the concern of
>    XPath: http://www.w3.org/TR/xpath
>    and XPointer: http://www.w3.org/TR/xptr
> 
> 4) The names of archive download locations are (almost certainly) URIs,
>    and URIs are well-defined attribute values in many many elements. So
>    think twice or even three times before consigning them to line-oriented
>    character data in the element content. (See below for " comment)
> 
> 5) Fetching tar.gz files or whatever from one of a set of download
>    locations can be viewed as "traversing" an "extended link" (generalized
>    many-to-many hyperlinks) of the XLink recommendation:
>    http://www.w3.org/TR/xlink
> 
> 6) I am not trying to just dump homework on you. I have not read all of these
>    TR's in detail, and you need not read them. I don't use namespaces and
>    XSL and XSchema, because frankly they are far too much trouble for the
>    toy uses to which I put XML. But you should think--just like the division
>    between the DTD and the document instance--about the "natural domain" of
>    any further C coding you do. By "domain" I mean think of whether it belongs
>    most naturally to the problem of XML parsing (constructing the sequence of
>    entities/tags/elements/attributes/content), or to the problem of an XML
>    application that consumes the resulting sequence. You may find that you
>    are doing parser work, and you might contribute to some of these W3C
>    efforts (if indeed you don't already).
> 
> 7) A concrete example of my concern is this: Do you envision LFS profiles
>    being "processed" or "transformed" (or even "browsed") by some other
>    generic XML handling program, like Windoze/XMLpad or fed raw to Mozilla?
>    Well the <include> element as discussed/fantasized about on the list
>    would be a major problem, as it effectively re-introduces the entity fetch
>    stage in the document instance! It is like keeping the compiler around at
>    run time "just in case we forgot to compile something we can just eval()
>    it"
>    SGML purists would scream at the unification of these stages they tried so
>    hard to keep separate. Might as well call it <magic> (or <!ENTITY...).

Both XInclude and XLink have been mentioned and suggested on the list before,
and I have to admit that I might rushed a bit with implementing <include>
without giving them more chance. I was probably too impatient to finally
allow splitting of profiles.

Since I'm not a XML expert and haven't yet read much of the above
specifications (but I _will_ do my homework :), I cannot comment much
on them. You're raising a lot of good points and ideas, but I myself have
probably more questions than answers on these issues.

For example, how should we start using them? By implementing them on top of
expat, by switching to other parser like libxml (which supports some of the
above), or use some other libraries (if they exist) etc. etc.

I'm willing to try all approaches if needed, if somebody points me to
the right direction. :)

My main concern is - if we start following those specifications, how far
could we get with using _only_ them and be conforming. I mean, we might
get to the point where we need something that isn't covered there. And then
again, we would have to add something ALFS-specific (like that entity
fetching you're mentioning, although that's just an example). I wouldn't
want that we have to abandon some good ideas/features because of it.

OTOH of course, it might be good that we follow some of those standards
(recommendations), as much as we can. It would be nice allowing other
software to use the profiles. For example, one could use a good, already
existing XML editor to edit the ALFS profiles.

Again, since my knowledge of XML (and friends) is pretty basic, I might be
talking pure nonsense here. :)

I'm definitely going to start digging into this more.

> ----------------------------------------------------------------------
> Part Three: Expat may have to be patched or abandoned.
> 
>    I am sorry about the problem with " et al. entity resolution
>    in expat. I have had to patch expat myself to process documents with
>    control characters in them. My feeling is that there are some tiny bugs
>    in expat; but that is a serious accusation since James Clark is no fool.
>    But expat may have to be patched or abandoned. Quote handling is important

I never had a problem with " and expat. Perl's FE_BE is the only place
where the problem is visible, so it can only be something with XML::Parser
or XML::Twig. XML::Parser is build on top of expat, but nALFS, which uses
only expat, doesn't have any problems with " inside attribute values.
I'm just realizing that I haven't yet searched the Net about this issue,
maybe we could come up with something there? Has anybody already tried that?

BTW, I would be interested to see that patch for expat you're mentioning
for parsing profiles with control characters. For example, my .vimrc has
some, so I can't just put it into <textdump> and then parse the profile.
Is that the kind of problem that could be solved with it, or am I
misunderstanding you? It would be very useful to allow something like that.

> ----------------------------------------------------------------------
> Part Four: Requested nALFS features. (What letter would be complete without?)
> 
>    Requested nALFS features: How about a time stamp issued in the log message
>    when execution of some key elements (<package> or <chroot>) begin running?

Already done :). I'm logging times before and after <package>, <prebuild>,
<build> and <postbuild>. I might do that for <chroot> too.

>    How about a mode to log commands instead of executing them
>    (like "make -n"),
>    and a mode to suppress the stdout of currently running commands (good for
>    modem users). I made some mods to do these things, but since the execution
>    of commands is spread throughout the handler *.c modules, I didn't nail
>    down every path of execution. Well, actually, in light of previous comments
>    about the separation of "compile time" and "run time", I think I would just
>    use #defines to wrap all the chdir() and chroot() and exec() calls. So you
>    would have to decide at compile time if you wanted to build a nALFS that
>    would actually do stuff, or just print stuff. Then there's the issue of
>    fork() and wait()...well, I would actually suggest you work on other
>    people's suggestions first!

Good suggestions. I've put them in TODO now, they won't be too difficult
to implement.

> ----------------------------------------------------------------------
> Part Five: A SECOND GIANT THANK YOU for writing nALFS, a wonderful program!
> 
> ----------------------------------------------------------------------
> Chris Bopp, cpb at log2.net

Thanks for a great input,

Neven

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list