IPC, RPC, Protocol to use between fe/be?
nomis80 at videotron.ca
Sat Jun 16 08:00:14 PDT 2001
On Saturday 16 June 2001 2:30, Jesse Tie Ten Quee wrote:
> You know.. i think someone said something similar to that effect about perl
> when it first started, i think everyone has proved that wrong so far, i
> don't want to limit us in any way, which i doubt anyone would, but...
This is too far-fetched. Just take a look at the facts. We take a shell
script, we add contextual information to the commands, and that's it. What
can we do with that context information? And how would the context
information be any different from the one found in say a .spec file?
> Really, if we use RPM we would be stuck with a proprietary binary
> format, we would *need* to have RPM installed on that system, we could
> not use it on a Debian system, or a Slackware system, or even an LFS
> system without installing RPM.
We don't need RPM. We can use the format, use the libraries, but we can do
without RPM. This is RPM (the format) vs. XML, not RPM (the binary) vs. ALFS.
> I though we wanted to create a framework, not a solution.
If that's the case, then I think I'm going to not take part into the project.
I want to make something for which there's a need.
> All the profiles are right now, is a small, tiny, formatted text file.
Like a .spec file.
> We can extend the tags and the formatting as much as we want, we would
> not be restricted to a single tool or mothed, we would not be restricted
> to a single language or tool.. last time i checked, XML is only a text
> file, and every major language can parse text fairly well, no?
As would be a .spec file.
> As for using shell scripts... in my not so humble opinion, writting
> profiles as shell scripts is a hell of alot harder then writting them in
> a markup language.
What you're writing in your profile is exactly a shell script!
> We do, after all, want to make it easy for everyone and anyone to make
> ALFS profiles, right?
People will have tons of ideas, and they'll think, "ok, I need to do action X
there", and they will think "hum... i'd need ln (or cp, or mv, or anything
else)" and then "what is the ALFS tag for that shell command?". Don't tell me
shell scripts are tough. When you're writing an ALFS profile, you're thinking
in terms of shell script.
> Sure, using shell scripts would give the user alot of freedom...but that
> also gives us no control, with XML tags it only defines the data, not
> *how* it's suppose to be executed, or anything else, just the
> infomration it will need to get the job done, it could care less how it
> is done, in what language, or anything else, as long as the effect is
> the same when it's finished.
As I said, XML contextualizes the information. What do you want that info for?
> Now, these comments are more web-oriented, but read them and think about
> what is said, id put more here, but...if you want to know more, buy the
> damn book =)
I think I understand pretty well what XML is and what it is not, thank you. I
think XML isn't suited for the task at hand.
> I'll keep digging for more reasons to use XML if you guys want and
> better descriptions and everything else why XML is "better" then
> anything else, but... the more time we waste talking about why XML is
> the "right" thing to use, the more time we waste ;)
I just think I'll step aside and look, as I'm still not convinced.
Simon Perreault -- Public key: http://nomis80.linuxfromscratch.org/nomis80.gpg
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the alfs-discuss