Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-installer
Navigation:
Lists: gentoo-installer: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-installer@g.o
From: Paul de Vrieze <pauldv@g.o>
Subject: Re: New class diagram and use case
Date: Tue, 3 Feb 2004 20:12:04 +0100
On Tuesday 03 February 2004 17:46, Eric Sammer wrote:
> Paul de Vrieze wrote:
> > On Tuesday 03 February 2004 04:37, Eric Sammer wrote:
> >
> > Just remember to use a progressive xml parsing strategy like SAX (forget
> > DOM) so at least you can do things as pause. In this case you just do
> > things as you find them in the xml file. If the file/pipe blocks you
> > have a pause, else you continue, all for free.
>
> I almost always use sax because of the memory footprint size compared to
> DOM. That said, the XML parsing would have nothing to do with pausing.
> The profile would be parsed to an object if we're loading one and as the
> user goes through the process, instance variables would be filled in in
> the GLIInstallProfile object. Once it was done, a call to serialize()
> will build and write the XML. So, they are 100% separate and one would
> never effect the other.

I don't see what you mean with GLIInstallProfile, but there are basically two 
cases:
- single xml file
- multiple xml files (possibly a way to put multiple ones into one file)

In the case where there is a single xml file it is necessary that the backend 
is able to allready perform tasks at the moment that a complete task has been 
received (but following tasks not yet). As DOM works in a parse completely 
first way it is inappropriate (unless there is a dom that doesn't work that 
way).

Say that the interface between the backend and the frontend is a pipe. In that 
case a way to control the backend would be by sending an xml file over. 

How would that work together with an interactive frontend. The backend would 
try to read the pipe. At the moment that a task has been closed it will 
execute the task. If there is a task in the pipe's buffer at that moment it 
will execute the next task etc. If there is no task in the buffer, the pipe 
will block and the backend will automatically pause until the frontend tells 
it to do more.

For the backend it would not matter whether all the tasks are comming from a 
file, at once from the frontend or gradually by the frontend.

I don't care that much how or if you implement this in the frontend, but 
implementing it in the backend (where it is simpler anyway) would make it 
easy to add interactivity in a later stage.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net
Attachment:
pgpqgIpeEPgOr.pgp (signature)
Replies:
Re: New class diagram and use case
-- Nathaniel McCallum
References:
New class diagram and use case
-- Eric Sammer
Re: New class diagram and use case
-- Paul de Vrieze
Re: New class diagram and use case
-- Eric Sammer
Navigation:
Lists: gentoo-installer: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: New class diagram and use case
Next by thread:
Re: New class diagram and use case
Previous by date:
Final pre-code meeting for Gentoo Installer
Next by date:
Re: New class diagram and use case


Updated Jun 17, 2009

Summary: Archive of the gentoo-installer mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.