From: Eric Sammer <esammer@gentoo.org>
To: gentoo-installer@lists.gentoo.org
Subject: [gentoo-installer] Some clarifications and a plea
Date: Tue, 03 Feb 2004 17:24:02 -0500 [thread overview]
Message-ID: <40201F82.2000509@gentoo.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 4461 bytes --]
I wanted to clarify some of the things in the last few emails because I
think a few things are happening. These include, but are not limited to,
people assuming certain implementation details, implementation being
focused on too tightly, and a lack of reading (or rereading) some of the
documentation.
To clarify the front end / back end discussion...
The "front end" and "back end" are just terms used to describe two
different sections of code. They are NOT two different applications.
They are NOT a client and server. They are the SAME executable package
meaning that no IPC method such as pipes be used to communicate between
them. They are the same code. Normal method calls can be made between
them. If need be, we'll change all references to front end and back end
to "code base." There is one application, one API and they are the same
thing. People are getting hung up on the idea that they are separate or
two independent "things" that need to "communicate." They aren't. No XML
messages or pipes are used, just plain old fashioned python method calls.
To clarify XML vs. object representation of data...
XML is used ONLY for the format of serialized files in the installer.
There's no XML messaging, passing of XML, or XML "stuff" going on in the
installer. There are objects (classes) that represent the parsed form of
an XML file. This is a data object and both GLIArchitectureTemplate
and GLIInstallProfile are good examples of this. When the installer
needs to load a profile, it creates a new GLIInstallProfile, calls
object.parse("/path/to/file.xml"); and all data is parsed and stored in
instance variables in the GLIInstallProfile object. The XML that was
parsed in memory disappears and goes away. It's not needed anymore. We
can pass the GLIInstallProfile object around to different classes in the
installer (this how user selections are "passed" between the front end
and back end, if I dare say so) as a solid collection of all options. It
could be incomplete, it could be complete - don't worry too much about
it. When all choices are made IF the user wants to be able to recreate
the installation, they can opt to serialize GLIInstallProfile back to
XML. This is entirely separate from installation, passing of data, etc.
and doesn't matter. It's a separate action. XML is just a file format in
our case, not a messaging system. The object representation form of the
profile is a regular python object - not an XML stream or anything that
has to be parsed.
If you have "partial" installs or whatever broken wackiness we want to
try and accommodate, you simple don't fill in everything in the
GLIInstallProfile and the back end won't do it (don't worry too much
about it - it WILL get figured out and is mostly just implementation
talk about a system with no implementation yet). There's no "feeding XML
to the back end" or other such things. There is nothing in the design
that will prevent manual intervention, or other things.
To clarify the immediate action vs. postponement of all actions until
the user has selected all options discussion...
Yes, you will be able to do it. No, not initially. Yes, the current
design will allow for its addition in a simple and efficient way.
I understand that no one trusts the installer yet. There's no reason to
- there's no code. That also means there's no reason to distrust it
either. If people want to do things manually, that's great, but I'd
rather make sure there's no *reason* to do so. Rather than figure out if
you will be able to (and you will, I promise) please tell us what you
want to do that just (seemingly) can't be done given a user interface
(and don't revolt - a plain text interface is still a user interface)
with proper options.
I promise you'll be able to...
- define your own custom steps
- use your own special commands in custom steps and default steps
- write your own special arch templates (see previous item)
- write profiles by hand without using any user interface other than vi
(emacs won't be compatible, mind you)
- load and save profiles for later use
- run commands atomically OR after each step
- do whatever voodoo you want to do by hand between steps
As much as I hate to say it (again), this is all covered in the docs
that were written, as well as the two diagrams. So, that URL again is:
http://www.gentoo.org/proj/en/releng/installer/
--
Eric Sammer
Gentoo Linux
http://www.gentoo.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
next reply other threads:[~2004-02-03 22:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-03 22:24 Eric Sammer [this message]
2004-02-03 22:27 ` [gentoo-installer] Some clarifications and a plea Andrew Gaffney
2004-02-03 22:41 ` Eric Sammer
2004-02-03 22:42 ` Paul de Vrieze
2004-02-03 22:51 ` Eric Sammer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40201F82.2000509@gentoo.org \
--to=esammer@gentoo.org \
--cc=gentoo-installer@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox