On Thu Apr 29 17:09:15 2010, bear wrote:
On Thu, Apr 29, 2010 at 12:04, Dave Cridland <[email protected]>
wrote:
> (16:40:59) Send (4340)
...cutting example xml...
>
> That's the traffic that identi.ca sent me for a "micro" blogging
entry, as
> an excerpt from my local server's telemetry log - so that's 4340
octets on
> the wire.
>
> This seems fairly drastically wrong - we should surely be able to
work out
> something better with the expertise we have here.
>
> Any obvious first steps? Lose the Atom? Make XHTML-IM optional?
How might we
> avoid forcing options on users? Disco for capabilities with
positive
> stickiness?
IIRC the issue is that they want the display capabilities that
XHTML-IM affords but not all clients handle it the same so they
repeat
the data. The Atom portion is now standard for OMB and Activity
Streams.
Well, the XHTML-IM bit really isn't the issue. I can live with that.
The Atom portion is insane, when I'll bet 99% of recipients will
ditch it anyway.
IMO clients and servers should now "do the right thing" with Atom
payloads and we can get rid of most of it.
What's the "right thing"?
Should my server know, and be able to parse, Atom?
Should my server just offline messages as just the <body/>? (That'd
really shrink things down).
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
