[9fans] XML

[ron minnich]

This one is interesting:
"The acmpolicy class implements a compiler for translating an XML policy
into their binary format and provides functionality for comparing a
current policy against a new one when changing a policy."

So, translate XML to binary to use it?

But it's a standard, right? I can't tell you how many times a day
people tell me they're doing something in XML ... "it's the standard"
-- not "A", but "THE".

Let's see:

<9p><request>T</request><requesttype>R</requesttype><fid><number><digit><binary>1</binary><binary>0>/binary>...

well, you get my drift.

Shouldn't we move 9p to a standards-based, compliant, XML-based system
with first-class enumerated elements in which all pluggable components
are Python objects and hence first-class citizens and add a full
compiler to enable translation and XML co-processor acceleration?

Can I randomly permute the words in the previous sentence? Yes.
Is that sentence like stuff I read nowadays? Yes.
Is constant gnashing wearing off the enamel on my teeth? Yes, oh yes.

ron

[W B Hacker]

Not to worry!

Sign of the times.

'Standards based' has simply replaced 'they say' as the biggest liar in the world.

Going the other way, we can now shave 3 bytes:

'progress' can be expressed as 'bloat'

Bill

[Roman Shaposhnik]

On Mon, 2007-05-21 at 09:57 -0700, ron minnich wrote:
> <9p><request>T</request><requesttype>R</requesttype><fid><number><digit><binary>1</binary><binary>0>/binary>...

ROTFL ;-)

Seriously, though, we all hate XML so much for all the right reasons
that we kind of forget that it can be useful. I do have a couple of
use cases I consider XML being appropriate at. But what about you guys?
Do you remember XML being helpful on any particular occasion? I'm really
curious.

Thanks,
Roman.

[W B Hacker]

Roman Shaposhnik wrote:
> On Mon, 2007-05-21 at 09:57 -0700, ron minnich wrote:

>> <9p><request>T</request><requesttype>R</requesttype><fid><number><digit><binary>1</binary><binary>0>/binary>...
>

> ROTFL ;-)
>
> Seriously, though, we all hate XML so much for all the right reasons
> that we kind of forget that it can be useful.

ACK.. And ingesting tapework scollix can help one lise weight...

> I do have a couple of
> use cases I consider XML being appropriate at. But what about you guys?
> Do you remember XML being helpful on any particular occasion? I'm really
> curious.
>
> Thanks,
> Roman.
>
>

If printed out on sufficiently soft paper, yes, XML is as useful as any other
drivel.

But few printers, laser or inkjet, can handle roll-feed, quilted and puffed or
otherwise.

;-)

Bill

[ron minnich]

On 5/21/07, Roman Shaposhnik <r...@sun.com> wrote:

> Seriously, though, we all hate XML so much for all the right reasons
> that we kind of forget that it can be useful. I do have a couple of
> use cases I consider XML being appropriate at. But what about you guys?

It's good at what it's good for. I think the move to XML as the
universal glue is more driven because people are desperate for
something and XML is all they can see .

But it's very sad to see people talking about binary converters and
XML co-processors, or to watch 100 bytes of data contained in 3000
bytes of XML ...

ron

[Francisco J Ballesteros]

> > Do you remember XML being helpful on any particular occasion? I'm really
> > curious.

In omero, I've found recently a place where using XML to convey the UI tree from
the UI server to the viewer would win (perhaps) wrt using a file tree.
this particular
case is when the link between the omero server and the UI viewer has a
really bad
latency. In this case, the current viewer scans the tree (one level at
a time) to see
changes and update the UI. Even when notified of subtrees that changes, it still
has to read the root of the subtree (one RPC), do the same for inner
panels (another),
and so and so and so.

However, we're still experimenting with this and I think that just
placing a "toc" file
in the root of the tree (with the equivalent of du -a) would permit
the viewer doing its
work in just two RPCs.

Of course, using a real fs instead of xml lets us use all the fs
tools, as you all know,
that's why we don't actually use xml. But since you asked, I have to
say that that's
the only place I've seriously considered using xml (or similar) to
replace a file tree.

Perhaps others have more cases where xml could be helpful.

[Bakul Shah]

> Shouldn't we move 9p to a standards-based, compliant, XML-based system
> with first-class enumerated elements in which all pluggable components
> are Python objects and hence first-class citizens and add a full
> compiler to enable translation and XML co-processor acceleration?
>
> Can I randomly permute the words in the previous sentence? Yes.
> Is that sentence like stuff I read nowadays? Yes.

Can you please use XML tags for humor? That'd make humor
recognition a purely parsing problem. Thanks!

In a previous job I used sexprs for flinging structured data
about between nodes. I justified their use as compiled XML.
You can guess what happened once I left....

> Is that sentence like stuff I read nowadays? Yes.
> Is constant gnashing wearing off the enamel on my teeth? Yes, oh yes.

Use of a dental nightguard is recommended.

[Uriel]

On 5/21/07, Roman Shaposhnik <r...@sun.com> wrote:

> Seriously, though, we all hate XML so much for all the right reasons
> that we kind of forget that it can be useful. I do have a couple of
> use cases I consider XML being appropriate at. But what about you guys?
> Do you remember XML being helpful on any particular occasion?

No.

But XML creates jobs, so it must be good for the economy.

uriel

[erik quanstrom]

> Seriously, though, we all hate XML so much for all the right reasons
> that we kind of forget that it can be useful. I do have a couple of
> use cases I consider XML being appropriate at. But what about you guys?
> Do you remember XML being helpful on any particular occasion? I'm really
> curious.

i think a better question is, can you think of an application for xml that
can't be done more simply?

the debate over typed variables in programming languages is pretty well over.
but i think asn/1 and xml seem to show that data type definitions can get
out of control. and that the dtd is itself a program that needs debugging.

- erik

[matt]

ron minnich wrote:
> This one is interesting:

Parse error, expecting something interesting, got old discussion about
XML being used because its fashionable.

[Uriel]

On 5/21/07, erik quanstrom <quan...@coraid.com> wrote:
> i think a better question is, can you think of an application for xml that
> can't be done more simply?

"The essence of XML is this: the problem it solves is not hard, and it
does not solve the problem well." -- Phil Wadler, POPL 2003

> the debate over typed variables in programming languages is pretty well over.
> but i think asn/1 and xml seem to show that data type definitions can get
> out of control. and that the dtd is itself a program that needs debugging.

If you think DTDs are out of control, you should look at XML Schema
some time... gives a new dimension to the meaning of 'megalomaniacal'.

uriel

[Skip Tavakkolian]

> Seriously, though, we all hate XML so much for all the right reasons
> that we kind of forget that it can be useful. I do have a couple of
> use cases I consider XML being appropriate at. But what about you guys?
> Do you remember XML being helpful on any particular occasion? I'm really
> curious.

its usefulness is largely due to the critical mass of software that
now supports it. popular browsers support DOMParser, XSLTProcessor,
etc. other approaches -- sexpr and sexpr with embedded js for
transformations -- would be as useful.

XML's ornateness reminds me of the historical accounts of the French
aristocracy just before the revolution; wasteful opulence manifesting
itself in how people dressed: wigs, massive makeup and ridiculous
outfits. it can't possibly last.

p.s. obviously, i'm wrong:

http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=89&articleId=9020222&intsrc=hm_topic

[Geoffrey Avila]

On a related note:

Somebody at Sun decided that the thing Unix needed most of all was a way
to programmatically manipulate "init" via XML. What's worse is that a
completely independent team at Apple committed a starkly similar atrocity
at almost the same time.

http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.html

http://developer.apple.com/macosx/launchd.html

Could someone explain this to me? Why would you do this? How could this
possibly be a net improvement?

-GBA

[Jack Johnson]

On 5/21/07, Skip Tavakkolian <9n...@9netics.com> wrote:
> etc. other approaches -- sexpr and sexpr with embedded js for
> transformations -- would be as useful.

What do you think would be the fastest/best way to implement something
like this as a proof-of-concept or stepping stone?

-Jack

[Uriel]

A GSoC student is implementing a 9P client in JS, that will be a nice
first step to replace the AJAX XML crud.

uriel

[Uriel]

You have no heart, programmers have families to feed! This will keep
hundreds of programmers employed for years to come.

uriel

P.S.: And be careful, you might offend the Apple and Sun fanboys in
the audience.

[Skip Tavakkolian]

>> etc. other approaches -- sexpr and sexpr with embedded js for
>> transformations -- would be as useful.
>
> What do you think would be the fastest/best way to implement something
> like this as a proof-of-concept or stepping stone?

not exactly plan9 related, but...

i assume the consumer will be a browser. probably do one in
javascript. despite its name, XMLHttpRequest can fetch anything.
check out the link below and take a look at jabberzilla sources on
code.google.com.

http://javascript.crockford.com/little.html

could just use an rc script to generate the content, probably using
this handy program: /n/sources/contrib/rsc/cgi.c

[Geoffrey Avila]

On Mon, 21 May 2007, Uriel wrote:

> You have no heart, programmers have families to feed! This will keep
> hundreds of programmers employed for years to come.
>
> uriel
>
> P.S.: And be careful, you might offend the Apple and Sun fanboys in
> the audience.

As a self-described Apple/Sun "fanboy", I'm trying to figure out why two
normally mostly-sane companies would willfully mutilate their OS in this
particular manner. I've never heard a peep out of anyone claiming how the
problems they sought to remedy with these new methods were insurmountable
w/o spraying XML all over the place...

-GBA

[David Leimbach]

I've actually seen FPGAs set up for XML processing... I thought that
was quite amusing :-)

[David Leimbach]

On 5/21/07, Roman Shaposhnik <r...@sun.com> wrote:

XHTML, on the surface, seems better thought out than plain old HTML.
That doesn't mean I like any of them though :-)

I once wrote a paper in Docbook, and was able to convert it to a PDF
via about 4 passes of XSLT processing. Then I remembered that LaTeX
can do that a lot faster, and never went back to Docbook. Not to
mention Docbook causes RSI faster than LaTeX from my experience with
badly hurting wrists and numbness in my fingers from all the <>\ etc.
:-)

XML has succeeded in making me accept and write more Lisp/Scheme these
days which isn't too bad for well roundedness.

Also some friends of mine and I have an XML markup based archiver for
files on various Unix like OSes called "xar". I think it started as a
joke but it's so good at backing up resource forks, extended
attributes, and other nuances of various unixes of the day that I've
started using it for backup purposes on Mac OS X :-)

Apple even picked it up, made a bunch of changes, and gave us some
patches. It might just end up in Leopard.

If you care:
http://code.google.com/p/xar/

It's been fun to hack on anyway. Not that I've done much with it in a while.

About the only really neat thing, I think, about the table of contents
being in XML is that you can embed subdocuments in the archives
themselves. Some folks started using it as a back end for packaging
systems, not sure if they ever completed. Apple might be one of them,
but I won't ever know until that next release is out.

It's not clear to me that XML is easy for either humans or computers
to read, which is what I thought was one of its selling points.

Dave

[erik quanstrom]

we feel the same way about iScsi hardware.

- erik

[Steve Simon]

I built a text file to described the menu interface for the LCD front panels
my employer makes.

Initialy I did this as an NDB-like file. I added the concept of a "end" keyword
to terminate a hierarchal block, and allowed a freestanding token to
imply a boolean token=true.

The DTD for this format was defined in another text file which was massaged by
a few lines of awk into an initialised table, compiled into all applications
that read the files (the format was fixed).

People didn't like it as it was not "standard XML" so when I have the chance to
rework it I went for XML and a DTD.

Personally I prefer the NDB style implementation, my compiled in spec gave much
more accurate validation than a DTD, and this was lightweight enought to be
easily be done on the embedded system.

Overall, having completed the changes a year or so ago, XML seems to have added
a load more angle brackets, quotes and poorer validation, in return for no real
reward.

But at least my files are now standard, so thats ok.

-Steve

[W B Hacker]

Geoffrey Avila wrote:
>
>
> On a related note:
>
> Somebody at Sun decided that the thing Unix needed most of all was a way
> to programmatically manipulate "init" via XML. What's worse is that a
> completely independent team at Apple committed a starkly similar
> atrocity at almost the same time.
>
> http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.html
>
> http://developer.apple.com/macosx/launchd.html
>
> Could someone explain this to me? Why would you do this? How could this
> possibly be a net improvement?
>
> -GBA
>

I'll try.

This presumes you have been around dogs.

Dogs have a way of ummhh.. 'grooming' themselves that (fortunately) most humans
could not manage alone. Not enough flex in the back and neck.

Can't speak to motivation...

Unfortunately, there are fewer such limitations in software development.

So - the reason for many of these departures' from common sense is the same as
that of a Northbound dog licking his Southbound end:

He does it simply because he is able to, and no one really cares to interfere.

Bill

[erik quanstrom]

any such dog would need to be straddling the south pole.
there can be at most one of these dogs at any one time.

;-)

- erik

[LiteStar numnums]

I have to disagree with Uriel here:
 I was on a project that went from using a simple scheme (Item-1-Name = ; Item-1-Price = )
to using XML. Each time I would add the feature that was desired by the Cabal of PHBs, they would think of another XML branch that they'd like to support for some other customer or system. Then it just went crazy: they wanted to hire an outside `architect` when I had been adding every feature piecemeal up until that point. Long story short, the project went over time alotment, the `architect` was an idiot, and I was laid off because the Cabal decided that they wanted to shift away from the bespoke app.
 I think the most fun was waiting for the 105MiB XML file to come down from the first client to be imported; I especially loved the repeated information within each <Item> </Item> block.
 I had asked to use either a web service or a simple CGI `API`, but no, it we *had* to pull from the clients. Cabal of PHBs + XML - Interest in funding design = steaming pile of manure.

--
"No stranger to me is this wanderer: many years ago passed he by.
Zarathustra he was called; but he hath altered.
  Then thou carriedst thine ashes into the mountains: wilt thou now
carry thy fire into the valleys? Fearest thou not the incendiary's
doom?
  Yea, I recognize Zarathustra. Pure is his eye, and no loathing
lurketh about his mouth. Goeth he not along like a dancer?"
-- The Saint, Also Sprach Zarathustra

[lu...@proxima.alt.za]

> P.S.: And be careful, you might offend the Apple and Sun fanboys in
> the audience.

Well I was horrified when NetBSD core seemed to be following in their
footsteps. Still am, but I have more or less been able to ignore the
issue.

++L

[lu...@proxima.alt.za]

Then Coraid is ripe for wrapping SCSI in XML. xSCSI anyone?

++L

[Charles Forsyth]

> Could someone explain this to me? Why would you do this? How could this
> possibly be a net improvement?

you probably want to ask about it in one of the sun or apple groups.

[Charles Forsyth]

> However, we're still experimenting with this and I think that just
> placing a "toc" file

i think just using s-expressions would do the trick, and be much easier to read.

[erik quanstrom]

i thought the criticism of s expressions was they were hard to read.

- erik

[Wes Kussmaul]

A dog straddling the south pole would have two north-facing ends.

Bill apparently meant south-facing end.

[erik quanstrom]

however, one end would be *heading* north. the other would be
*heading* south.

- erik

[Jack Johnson]

On 5/22/07, Wes Kussmaul <w...@authentrus.com> wrote:
> A dog straddling the south pole would have two north-facing ends.

Euphemistically, anything below the waist is the south end.
Therefore, the head is at the north end. All male dogs retaining both
rear legs and standing could be perceived as straddling its own
southern pole.

Thus, a male dog can never have an end facing south?

-Jack

[Bruce Ellis]

to throw a spaniard in the works (never was good at mangling metaphors)
i use XML to store midi patches and configs. as a human never edits
them directly (the pre-existing library does that) it was a good choice.
i considerered an ndb approach, and S-expressions, but i like what i got.

i could have invented a file format and implemented it but i chose not to.

you wouldn't want to read or write any configuration for something
with a thousand params but programs do it fine.

brucee

[Jack Johnson]

On 5/22/07, Bruce Ellis <bruce...@gmail.com> wrote:
> i use XML to store midi patches and configs. as a human never edits
> them directly (the pre-existing library does that) it was a good choice.

I actually think this is where Sun/Apple are headed, where either
settings are configured via some automated deployment/policy process
or UI interaction and it's not expected that a human will ever have to
deal with it (though they would not be prevented from doing so).

-Jack

[Wes Kussmaul]

Nothing on the plane of the surface of the earth at the south pole can
head or face south. Only something orthogonal to the surface (eg the
pole itself or perhaps a penguin's head) can point south.

wk

[Roman Shaposhnik]

That is one of those mysteries that just makes me sad :-(

Thanks,
Roman.

[Lluís Batlle]

I find that most of the tree-like information I want to store in a fd
fits well on OGDL (1st layer). I think Forsyth was working on a OGDL
parser in limbo - I don't know if he finished or stopped thinking on
it.

I wrote my own in c++, and I used a j2me implementation given in the
OGDL main site - them both work fine.

2007/5/22, Bruce Ellis <bruce...@gmail.com>:

[Lluís Batlle]

Lately I've been told at work to use a library in C. Most calls have
the signature
ErrorType function(const char *xml);

I have to pass to them xmls of more than two levels deep, attributes,
and around ten elements.

When I asked why such interface to a library, claiming that it was
uncomfortable to me, the lib developer told me that in fact
xml-parameter-passing was one of the techniques he liked most, and
helped him solve a lot of problems easily.

2007/5/23, Lluís Batlle <viri...@gmail.com>:

[lu...@proxima.alt.za]

> I have to pass to them xmls of more than two levels deep, attributes,
> and around ten elements.

Must do wonders for type and error checking.

++L

[David Leimbach]

To be completely honest, a bit of the history of xar was a joking
conversation by some friends of mine who happened to work at apple at
the time.

"Everything's better with XML, even tar". "XAR!" which is kind of fun
to yell came out of it.

Sadly I've found it useful after all of that was said and done. It's
really not too bad with the abominations that are extended attributes
(let's treat files as directories shall we? And hide all the data in
key value pairs... ), Finder Info on mac os x, resource forks, etc.
It's been working Ok on FreeBSD, Linux and Mac OS X, each with their
slightly different APIs for dealing with those little nuggets of joy.

And it's been re-written a few times. (because DOM is a horrible
waste of resources if you don't need it, SAX-like processing of the
XML posed an interesting challenge) I did compression on the XML TOC
myself to add more to the joke.

I mean when you have a table of contents in XML that's > 800 MB, you
gotta do something :-)

Anyway, it was originally just fun to work on, and probably serves
more as proof of how much XML sucks. However Apple's adopting it in
Leopard, probably due to the use of XML. Had we used S-expressions, I
don't think they'd have known what to do with it.

One of the leaders of the RPM project actually did something at some
point to try to use xar instead of cpio archives for a new RPM
back-end. I'm not sure it got anywhere. There was also a packaging
system that someone started called "xpkg".

Sometimes jokes get out of hand I guess.

[erik quanstrom]

> "Everything's better with XML, even tar". "XAR!" which is kind of fun
> to yell came out of it.

; wc -l /sys/src/cmd/tapefs/tarfs.c
140 tarfs.c

tar is not that bad a format to use for structured data. it's easy to implement.
you can capture data movement and fiddle with it easily.

that being said, i'd still much rather have a filesystem-like interface.

- erik

[Charles Forsyth]

> On 5/22/07, Charles Forsyth <for...@terzarima.net> wrote:
>> > However, we're still experimenting with this and I think that just
>> > placing a "toc" file
>>
>> i think just using s-expressions would do the trick, and be much easier to read.

i was referring specifically to nemo's application, although it's often true in general.
s-expressions can look reasonably attractive, and double-clicking works on them.
you can't say either about xml. certainly most xml i've seen makes me think i'm dyslexic.
it also looks constipated, and two health problems in one standard is just too much.

[Francisco J Ballesteros]

We're trying hard (by reading most of the tree concurrently, and using Op on the
slow link) to get o/mero fast enough not to worry about TOC. But in
any case, should we
add toc, probably just a raw list of, say, one relative path per line,
a-la-du, would suffice.

Anyway, time will say. :)

[ron minnich]

On 5/25/07, Francisco J Ballesteros <ne...@lsub.org> wrote:
> We're trying hard (by reading most of the tree concurrently, and using Op on the
> slow link) to get o/mero fast enough not to worry about TOC. But in
> any case, should we
> add toc,

I think that toc demonstrates the power of the approach, however.

I had this long running discussion on kvm devel list, trying to argue
for 9p as the interface for paravirtual devices. I think there is some
acceptance, but not total acceptance. People keep thinking that
emulation is the same as an abstraction. i.e. they argue that an
abstraction of an IRQ controller that has IRQ0-n, NMI, SMI, etc. The
abstraction is that the highest IRQ is not bounded as it is in real
life. Abstraction? Hmm. Not on my planet, anyway.

It hit me that the dom0 could export its tcp stack to dom1 as a
paravirtual device. you could bypass the silly virtual enet emulation
that way. Your /net would go right to the tcp, not via some odd
pseudo-device. That would save some delay and overhead, and, not
incidentally, would make my mp3 player smoother in dom1 ...

thanks

ron

[ozan s. yigit]

> i think just using s-expressions would do the trick,
> and be much easier to read.

json would probably be less of a trick.
oz

[Steve Simon]

> We're trying hard (by reading most of the tree concurrently, and using Op on the
> slow link) to get o/mero fast enough not to worry about TOC. But in
> any case, should we
> add toc, probably just a raw list of, say, one relative path per line,
> a-la-du, would suffice.

I am not sure I understand your application, but
couldn't you implement it with a single virtual file that the window
manager creates, and which the remote client blocks on. When the
user changes the layout the info is written to the "changes" file.

Thus the remote end can keep a cache of the window systems state
close to it by just reading a single file rather than scanning the
widget hierarchy.

-Steve

[Uriel]

On 5/25/07, ron minnich <rmin...@gmail.com> wrote:
> It hit me that the dom0 could export its tcp stack to dom1 as a
> paravirtual device. you could bypass the silly virtual enet emulation
> that way. Your /net would go right to the tcp, not via some odd
> pseudo-device. That would save some delay and overhead, and, not
> incidentally, would make my mp3 player smoother in dom1 ...

Same goes for graphics, dom0 could export a /dev/draw and /dev/cons
and you could have the hosted OS transparently in a window, even if it
had no virtual video hardware.

uriel

[Charles Forsyth]

no, i don't think so. they're about the same amount of code, and json is
less regular and more of a hack. as js is, though i've seen worse
(java! oh, man! what were they THINKING?)

[Francisco J Ballesteros]

We have something similar. When layout changes, an event is posted to /mnt/ports
but that reports that a subtree changed. At that point, we must reread
the subtree to
detect changes. Knowing the dir hierarchy in advance can speed things
up, and the
toc file could be of help.

But thanks for the idea. I'll give it a second thought.

[erik quanstrom]

On Fri May 25 14:15:01 EDT 2007, rmin...@gmail.com wrote:
> It hit me that the dom0 could export its tcp stack to dom1 as a
> paravirtual device. you could bypass the silly virtual enet emulation
> that way. Your /net would go right to the tcp, not via some odd
> pseudo-device. That would save some delay and overhead, and, not
> incidentally, would make my mp3 player smoother in dom1 ...

muxing a /net heirarchy from plan9 via 9p is certainly the most flexable
way to go. this is a very good idea. (i assume that you really didn't
mean importing tcp only from dom0.)

however, there are some hardware models that could be very efficient
to emulate in /a/ hypervisor. the myricom 10gbe moves all data
by dma. the only mmio is for commands, send descriptors (16 bytes)
and receive descriptors (8 bytes). assuming the guest doesn't have
real pci window addresses, dom0 would only need to rewrite the
descriptors and the card could still dma directly from the guest.

it's significantly less general than the 9p way of doing things, but
it could make zero-copy sends (and zero-copy tco, if you care about
such things) doable.

i don't know enough about xen's inner workings to know if this would
work.

- erik

p.s. perhaps the way to put generality back in is to marshal 9p between
dom0 and guests with the same trick. use an pseudo-mmio descriptor for
the 9p "header" which points to the memory to be transfered.