Dear all,
I believe combination of XMPP and EXI should have great synergy and can
extend the world of XMPP far more. However, because this space is very
wide and I think it's better to clarify requirements on this
combination, mainly towards IoT/M2M/sensor network use case of XMPP.
Let me start with enumeration of problem spaces.
- Minimal client requirement
How small a client implementation should be?
- Minimal server requirement
How small a server implementation should be?
- Message Efficiency requirement
How small a message should be?
- Schema management (in a communication and in the whole system)
How do we manage schema and its variants?
- (maybe more axis should be there)
In this mail, let me start with client/server requirements.
I think it is clear:
server requirements >= client requirements.
to make things work.
Choice would be something like this:
- Should a node accept plain text XML, in addition to EXI?
- Should a node accept introduction of new schema-informed grammar?
- Should a node accept various set of options? Which option should be
selectable per session?
Combination of client and server requirement could be something like the
followings:
[Proposal just for communication efficiency]
- Server and client should accept various EXI options and dynamic schema
installation in addition to plain XML communication handler.
[Proposal for extremely constrained clients]
- Client may implement only EXI-based, fixed schema set. The client may
be able to notify/upload the implemented schema set to its corresponding
server.
- Server should implement both EXI and XML with dynamic schema
installation with appropriate limited set of options.
Many other combination should be considered. Even binary-only servers
could be possible. Of course, interoperability between current XMPP
implementations will be lost without further consideration like
Server-to-Server proxy.
Summary:
I think EXI is so flexible and thinking about 'what we really want to
do' will greatly help to cut down the huge problem space.
Regards,
// Yusuke DOI <[email protected]>
