[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix-xml] Re: Proposal for Alternate oBIX Encodings
|
Perhaps Fast Infoset. http://en.wikipedia.org/wiki/Fast_Infoset or FAST http://code.google.com/p/quickfast/ or are you looking at something like an ASN1 encoding… tc "A man should never be ashamed to own that he has been in
the wrong, which is but saying ... that he is wiser today than yesterday."
-- Jonathan Swift
From: Considine, Toby
(Campus Services IT) [mailto:Toby.Considine@unc.edu] I heartily approve! If the Calendar Consortium brings their stuff forward early, we
can add it. tc "A man should never be ashamed to own that he has been in
the wrong, which is but saying ... that he is wiser today than yesterday."
-- Jonathan Swift
From: Brian Frank
[mailto:brian.tridium@gmail.com] Now that summer is winding down, I'd like to get some
thoughts on doing a binary encoding for oBIX and finalizing the 1.1 draft. In the most recent IETF meeting, it was decided to form a
new working group for an application level protocol to run over 6LoWPAN.
I have submitted a Internet Draft for a compressed UDP version of HTTP: Who knows where an IETF standard might wind up, but I am
hoping that it will be HTTP based and address resources with URIs. Of course, we still need a modeling and payload encoding for
data. I think a binary encoding of oBIX would be a perfect fit for this
brave new world! I would like to propose adding a chapter to the oBIX 1.1
specification for binary encoding. Assuming we
are satisfied with that, I would like finalize 1.1 as a specification
with the new content on timezone, time, date, and binary encoding. Although
Aaron has written an iCAL scheduling draft, I don't think we have any
implementations - so I would suggest taking that off the table for 1.1 and
instead focus on releasing a 1.1 this year. What do you guys think? Brian On Tue, Mar 31, 2009 at 11:25 AM, Frank, Brian <bfrank@tridium.com> wrote: Today
oBIX defines an abstract object model with a single encoding based on XML.
But the original vision behind oBIX was that multiple encodings could be
defined all sharing the same interoperable object model. I would like to
propose adding two alternate encodings of the oBIX object model to the 1.1
draft specification: JSON and Binary. One
of the things we are starting to see is many people are using oBIX as an AJAX
data feed to their browser. In this use case, it is preferable to deliver
the oBIX information directly in a JSON format rather than requiring JavaScript
to parse the XML into a usable format. Why
a binary oBIX encoding? This requirement takes a little more background
discussion. One of the technologies I have been deeply involved in is
6LoWPAN which is an RFC specifying how to run IPv6 over 802.15.4 wireless
networks. I firmly believe that 6LoWPAN has the potential to unleash the
Pervasive Internet by adding billions of new nodes to the Internet. But
putting these devices onto the Internet is just the first step. The next
step is to put them onto the Web so that they can be wired into humanities
existing information infrastructure. Due to their resource and power
constraints, 6LoWPAN devices cannot fully run HTTP or mange XML
payloads. To the solve the HTTP problem, I am working on an RFC to run a
compressed version of HTTP over 6LoWPAN. On the payload side, oBIX
fits perfectly for defining a RESTful information model. But we need a
compact encoding which can work with the small packet sizes required for
802.15.4 networks. I have some good ideas on how to achieve this without
loosing any of oBIX’s modeling capability. Clients
would perform negotiation with servers for their preferred encoding using the
Accept header (standard HTTP content negotiation). Comments? I
would suggest we try to setup a teleconference next week (Mon or Tue preferably)
to discuss this strategy. Brian |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]