| 1 |
On Tuesday 03 February 2004 17:46, Eric Sammer wrote: |
| 2 |
> Paul de Vrieze wrote: |
| 3 |
> > On Tuesday 03 February 2004 04:37, Eric Sammer wrote: |
| 4 |
> > |
| 5 |
> > Just remember to use a progressive xml parsing strategy like SAX (forget |
| 6 |
> > DOM) so at least you can do things as pause. In this case you just do |
| 7 |
> > things as you find them in the xml file. If the file/pipe blocks you |
| 8 |
> > have a pause, else you continue, all for free. |
| 9 |
> |
| 10 |
> I almost always use sax because of the memory footprint size compared to |
| 11 |
> DOM. That said, the XML parsing would have nothing to do with pausing. |
| 12 |
> The profile would be parsed to an object if we're loading one and as the |
| 13 |
> user goes through the process, instance variables would be filled in in |
| 14 |
> the GLIInstallProfile object. Once it was done, a call to serialize() |
| 15 |
> will build and write the XML. So, they are 100% separate and one would |
| 16 |
> never effect the other. |
| 17 |
|
| 18 |
I don't see what you mean with GLIInstallProfile, but there are basically two |
| 19 |
cases: |
| 20 |
- single xml file |
| 21 |
- multiple xml files (possibly a way to put multiple ones into one file) |
| 22 |
|
| 23 |
In the case where there is a single xml file it is necessary that the backend |
| 24 |
is able to allready perform tasks at the moment that a complete task has been |
| 25 |
received (but following tasks not yet). As DOM works in a parse completely |
| 26 |
first way it is inappropriate (unless there is a dom that doesn't work that |
| 27 |
way). |
| 28 |
|
| 29 |
Say that the interface between the backend and the frontend is a pipe. In that |
| 30 |
case a way to control the backend would be by sending an xml file over. |
| 31 |
|
| 32 |
How would that work together with an interactive frontend. The backend would |
| 33 |
try to read the pipe. At the moment that a task has been closed it will |
| 34 |
execute the task. If there is a task in the pipe's buffer at that moment it |
| 35 |
will execute the next task etc. If there is no task in the buffer, the pipe |
| 36 |
will block and the backend will automatically pause until the frontend tells |
| 37 |
it to do more. |
| 38 |
|
| 39 |
For the backend it would not matter whether all the tasks are comming from a |
| 40 |
file, at once from the frontend or gradually by the frontend. |
| 41 |
|
| 42 |
I don't care that much how or if you implement this in the frontend, but |
| 43 |
implementing it in the backend (where it is simpler anyway) would make it |
| 44 |
easy to add interactivity in a later stage. |
| 45 |
|
| 46 |
Paul |
| 47 |
|
| 48 |
-- |
| 49 |
Paul de Vrieze |
| 50 |
Gentoo Developer |
| 51 |
Mail: pauldv@g.o |
| 52 |
Homepage: http://www.devrieze.net |
Archives