[9fans] XML - Plan9

This is a discussion on [9fans] XML - Plan9 ; On 5/22/07, Charles Forsyth 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 ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 51 of 51

Thread: [9fans] XML

  1. Re: [9fans] XML

    On 5/22/07, Charles Forsyth 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.
    >
    >

    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.

  2. Re: [9fans] XML

    > "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

  3. Re: [9fans] XML

    > On 5/22/07, Charles Forsyth 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.


  4. Re: [9fans] XML

    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.

    On 5/25/07, Charles Forsyth wrote:
    > > On 5/22/07, Charles Forsyth 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.
    >
    >


  5. Re: [9fans] XML

    On 5/25/07, Francisco J Ballesteros 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

  6. Re: [9fans] XML

    > 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


  7. Re: [9fans] XML

    > 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

  8. Re: [9fans] XML

    On 5/25/07, ron minnich 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

  9. Re: [9fans] XML

    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?)


  10. Re: [9fans] XML

    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.

    On 5/25/07, Steve Simon 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, 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
    >


  11. Re: [9fans] XML

    On Fri May 25 14:15:01 EDT 2007, rminnich@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.

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3