FAQ
Hello rsc@golang.org, chris@cjones.org, n13m3y3r@gmail.com (cc:
golang-dev@googlegroups.com),

Please take another look.


https://codereview.appspot.com/6868044/

Search Discussions

  • Chris Jones Yar at Dec 17, 2012 at 4:29 am
    Hello rsc@golang.org, chris@cjones.org, n13m3y3r@gmail.com (cc:
    golang-dev@googlegroups.com),

    Please take another look.


    https://codereview.appspot.com/6868044/
  • Russ Cox at Dec 17, 2012 at 4:19 pm
    I would like to drop Context from the API. Can we do that?
    It seems to me that even if you're in the middle of a document you can
    just introduce new prefixes as needed.

    Russ
  • Chris Jones at Dec 17, 2012 at 7:06 pm
    Thanks for reviewing. I don't know how you'd introduce a new prefix
    other than with a tag, and tags are static and difficult to use on an
    as-needed basis.

    But the problem is really more about introducing existing prefixes
    rather than new ones. Imagine you're emitting XML that's going to go
    into the middle of an XML doc, and some prefixes have already been
    declared in that doc. It would be clumsy to redeclare those prefixes, or
    to declare new ones for the same namespaces. An XMPP implementation
    almost requires this capability, and it's likely that other XMPP
    implementations wouldn't interoperate with those clumsily redeclared
    namespaces.

    An XMPP conversation consists of two XML documents, each being sent the
    opposite direction over the connection. The client's "document" starts
    with this:

    <stream:stream xmlns="jabber:client"
    xmlns:stream="http://etherx.jabber.org/streams" ...>

    Then, over the life of the connection, the client sends its commands to
    the server as a series of XML elements, all of which are implicitly in
    the "jabber:client" namespace. Notice there's no end tag for
    <stream:stream>. That means you can't send it using xml.Marshal() or
    xml.Encoder.Marshal() -- those both send end tags for every element. So
    you have to output that <stream:stream> header without going through
    Encoder. Somehow, Encoder needs to know that you've declared two namespaces.

    I'm not in love with Context, but I don't see a better way to do it. A
    full implementation of XML namespaces requires that you have something
    functionally equivalent to Context. The ability to stop and start in the
    middle of a document means we need to expose that information to the
    user somehow.

    Assuming you or somebody else doesn't see a better alternative to
    Context, here's a related question: Should we use type aliases on the
    keys and values of Context.Map? Currently it's map[string]string, and
    Encoder uses it as namespace -> prefix while Decoder uses it as prefix
    -> namespace. That feels dirty to me, and likely to cause confusion.

    Chris
    On 12/17/2012 9:19 AM, Russ Cox wrote:
    I would like to drop Context from the API. Can we do that?
    It seems to me that even if you're in the middle of a document you can
    just introduce new prefixes as needed.

    Russ
  • Russ Cox at Dec 17, 2012 at 6:54 pm
    Perhaps, but perhaps not.

    I think that if you need to send a <foo> in the jabber:client name
    space, you can always send

    <foo xmlns="jabber:client">

    instead of needing to know what the outer version is called.

    Russ
  • Chris Jones at Dec 18, 2012 at 4:43 am
    You're right, of course -- a document with redundant namespace
    declarations is technically compliant with the spec. Let me marshal
    (heh) my arguments against that, though:

    In my specific case, I'd worry that other XMPP implementations wouldn't
    interoperate with the extra namespace declarations. Such implementations
    would be buggy.

    In XMPP, every stanza I send would be qualified by the redundant
    namespace declaration. That's 22 bytes of extra data for every command
    sent to the server. I guess whether that's excessive depends on where
    you're coming from. It could be a lot more redundant data in other
    environments.

    From a purely aesthetic perspective, it seems icky to generate those
    redundant declarations, with no reasonable way of suppressing them.

    For unmarshaling, this all may be more of a concern. The current
    approach, which is to stuff unknown prefixes into the namespace field of
    xml.Name, is imprecise. I could construct a document that would cause
    the parser's output to be wrong, if you started parsing after the first
    element:

    <x xmlns:foo="ns1" xmlns:ns2="foo">
    <foo:z/>
    </x>

    And there's no straightforward way for me, as a user of encoding/xml, to
    set up the parser to do the right thing with this document if I have to
    parse an excerpt of it.

    Chris
    On 12/17/2012 11:54 AM, Russ Cox wrote:
    Perhaps, but perhaps not.

    I think that if you need to send a <foo> in the jabber:client name
    space, you can always send

    <foo xmlns="jabber:client">

    instead of needing to know what the outer version is called.

    Russ
  • Russ Cox at Dec 22, 2012 at 2:57 pm
    It's easy to handle the parsing half. Use the xml Decoder to read the
    first element, and it will have the appropriate context.

    For the printing half, I'd still like to avoid adding new API until we
    have a demonstrated need. Any XMPP implementation must parse XML, and
    what I've suggested is valid XML. It's true that it adds the 22 bytes
    or so to each message, but I've seen what XMPP messages look like: no
    one will notice 22 extra bytes. Also, if you're doing XMPP over TLS
    it's all getting compressed anyway.

    Russ
  • Chris Jones at Dec 28, 2012 at 7:53 pm

    On 12/22/2012 7:57 AM, Russ Cox wrote:
    It's easy to handle the parsing half. Use the xml Decoder to read the
    first element, and it will have the appropriate context.
    Good point, though you'd have to read just the start tag on that element.
    For the printing half, I'd still like to avoid adding new API until we
    have a demonstrated need. Any XMPP implementation must parse XML, and
    what I've suggested is valid XML. It's true that it adds the 22 bytes
    or so to each message, but I've seen what XMPP messages look like: no
    one will notice 22 extra bytes. Also, if you're doing XMPP over TLS
    it's all getting compressed anyway.
    I'll modify the patch accordingly and resubmit.

    Chris
  • Chris Jones Yar at Dec 29, 2012 at 12:21 am
    Hello rsc@golang.org, chris@cjones.org, n13m3y3r@gmail.com (cc:
    golang-dev@googlegroups.com),

    I'd like you to review this change to
    https://code.google.com/p/go


    https://codereview.appspot.com/6868044/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedDec 17, '12 at 4:29a
activeDec 29, '12 at 12:21a
posts9
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase