Re: [as-devel] 1.8 ?

Sasha_Vasko@osca.state.mo.us
Wed, 28 Jul 1999 09:34:13 -0500 




On Tue, 27 Jul 1999, Steven Baker wrote:

>>   The advantages of using XML are clear.  It is fast becoming a
>> standard, the next HTML DTD will be XML based, and many programs are
>> already using XML.
>
>Very true.  While the current learning curve to write this stuff by hand
>may seem steep (knowing HTML helps here), as XML becomes more common, it
>should become less so.  There are, as Steven points out, lots of apps
>that use it already, and more all the time, so there isn't a question of
>XML's future popularity - it's already popular.

Well, taking on account that most of us never had to deal with it
before, and scarcely knows, how it works gives slight indication,
that XML is not yet as popular and used, as  let's say HTML is.
Yes, it is definately becoming a standard, but it is not yet there.
As the result, complete move into XML should be postponed, untill it
becomes accepted by wide masses.
Althought if we have an eager volunteers to start working on XML support
now - there is a solution - optional XML support in AfterStep. As time goes by
and ppl getting more used to it, old format can be dumped altogether.
Here is how that could be implemented :

The new parser code that I wrote, was designed the way, that it consists
of several independent layers, effectively making adding/changing actual file
format - an easy thing to do.  Here is how it looks like :

Application
        |
        +---------- application specific data structure
        |
FreeStorage Processing
        |
        +---------- FreeStorage Data tree
        |
FileReader
        |
       +----------- config file

Application specific processing is done excusevely on 2 highest levels,
and FileReader has no knowledge about actual application, it is serving to,
whatsoever. At the same time highest two levels has no idea, what is actual
file format.  FreeStorage is a powerfull tree like data structure that serves as
intermediate between them.

Beauty of that is that most of the hard work ( and rather boring hard work it is
)
is located on higher levels, so when you want to switch to new file format - all
you do
is write a new FileReader - and off you go, you don't have to recode evry
single module.

FreeStorage as it is right know, has gone a long way from origianl Ethan's
proposal. It now can be orginized into tree structure, extremely well suitable
for
nested structure storing, which is very good for XML config reading as I
envision it.

Most infrastructure for producing FreeStorage from the raw data is already in
place.

If we have volunteers for integrating XML into this config reading stuff, I can
prepare
source tree for such a thing.

<THREAT>
At the same I would strongly oppose to recoding this whole structure, only to
produce something similar. It would take alot of time and resources, and I'm
pretty sure thatthose who'd undertake this will get bored, or side tracked in
the
middle of the works, and we'll get a bunch of unfinished code.
If somebody thinks that existing structure is very cumbersom and unneccessary
bloated - then be my guests and write your own version of it, if you'll manage
to do something better, which I doubt, I'll be glad to have it in the source
tree.
Beware thou that there are quite a few problems you'll have to solve, and result
will be far from what you envision now ( voice of experience ). Also in this
case
you'll undertake a responsibility of recoding every single module.
 </THREAT>


>> <look>
>>  ... Data for appearance.
>> </look>
>> <feel>
>>  ... Data for feel.
>> </feel>

>A good idea.  Difficult to implement, though.  Problem is, AfterStep's
>on-the-fly reconfiguration system assumes that reading certain files
>will define certain things.  For example, it deletes all MyStyles before
>reading the look file.  This idea is currently feasible, if we know in
>advance what tags (<look>, <feel>, etc) will be in the target file.

This could be easily implemented using FreeStorage.
You'd get something like :

FreeStorageHead()
{
     FreeStorageElem("look")
     {
          FreeStorageElem("MyStyle")
          {
               FreeStorageElem("name", "actual_name")
               FreeStorageElem("BackPixmap", "128", "filename")
               FreeStorageElem("Font", "fontname")
          }
          FreeStorageElem("MyStyle")
          {
               .
               .
               .
          }
     }
     FreeStorageElem("feel")
     {
          FreeStorageElem("RandomPlacement")
          FreeStorageElem("Function")
          {
               FreeStorageElem("name","function name")
               FreeStorageElem("Move",""Motion"")
                    .
                    .
                    .
          }
     }
}

such a structure will be produced as output of FileReader,
and afterstep can go through this whole thing as many times
as it wants to, withou need of rereading actual file.

If anyone has some questions regarding machanisms of
the parser - feel free to ask.


>Ethan Fischer

Sasha