[JDEV] Information Querying/Storage Proposal

[Jeremie]

Information Querying/Storage Proposal

This is a proposal to add an simple data storage and retrieval to Jabber
that will function in a general purpose way.

Goals: Handle the following
	User Information(Name/Address/etc)
	User Preferences(Common Client Prefs, colors, sorting, etc)
	Public Server Data(Online users, simple stats, site/help URL, etc)
	Private Server Data(Admins only, full stats, errors, security, perf)
	Private Client Data(Special purpose client-level queries)

Here is a possible simple protocol snippet to show how it might work:

<info>
	<to>jeremie</to>
	<target>user</target>
	<id>public</id>
	<query><name/><address/><email/></query>
</info>

This "info" packet would be sent from the client to the server, asking the
server for the name/address/email of the user "Jeremie".  It would be up
to the server/users privacy settings to decide, but a possible responce
might be:

<info>
	<target>client</target>
	<type>public</type>
	<result>
		<name>Jeremie Miller</name>
		<address>Some Street, City, State, 55555</address>
		<email>jeremie at jabber.org</email>
	</result>
</info>

The server would basically just "fill in" the query terms sent by the
client.


<target>***</target>
 -- Contains characters identifying what "area" this info is related to
 -- Possible Values:
	user: User specific level information, addresses, preferences, etc
	client: Delivered directly to the client software, responses and
		special queries
	server: Server specific information

<type>***</type>
 -- This is the specific item that the query/result is directed at
 -- Possibilities:
	public: Usually public information
	admin: Administrative protected tasks
	feature: Feature Negotiation
	private: Priavte only data

<query>***</query>
 -- Contains empty XML tags detailing the specifics of the data requested

<result>***</result>
 -- Should contain the queried XML tags filled in with the correct data,
which might itself be XML


This takes care of a simple data query/result situation, let's add in the
ability to change data also.

<info>
	<target>user</target>
	<type>public</type>
	<set><email>jer at jeremie.com</email></set>
</info>

By simply changing the <query> to a <set>, the data can be updated/stored.
This would of course only be allowed by an authenticated session from the
correct user account.


This appears to take care of most cases, and also allow for more
functionality in the use of Jabber.

Possibilities include:

 -- Using to store general client prefs:
	Create a list of standard client preferences, <audio>yes</audio>,
etc, that a client can optionally support

 -- Using to store client specific prefs:
	Clients can use a specific query such as <ClientSoftName>
<theme>asdf</theme> <startup>max</startup> </ClientSoftName> and the
server should store this and return it when asked.  This should only be
_client_specific_ data stored with a "priavte" type, all general
preferences that might apply to multiple clients should be turned into a
general list and posted in the client development requirements/guidelines.

 -- Using to query server variables:
	Special public server queries might include <help/> <info/>
<admin/> that any transport/server should respond to appropriately, with a
URL or other data. 

 -- Using to admin a server:
	Special administrative accounts might be able to query errors,
performance, connected users, etc.  They might also be able to set certian
items an change variables in the server on the fly or disconnect users. 

 -- Using for special client-level purposes:
	Queries can also be delivered to clients, although they are not
required to respond.  But special clients might be able to send back
transient data.  This would be a special purpose only client<->client
communication, where it is NON-USER-LEVEL data.  Anything user level or
that might interact with the user in any way should be done via the
<ext></ext> tags in a message.  There is the possibility for abuse here,
just note that the <info/> packets are for simple data/variable
querying/storage that is not user-level. Example: Temperature sensor!  A
small computer could be set up as a miniature weather lab with a few
sensors connected.  It could connect to a Jabber server as a client, and
it would update it's status regularly with the current temperature so
everyone with it on their roster would have the current temp.  But special
info queries could be sent to it to retrieve wind speed or to set update
intervals, etc. 

 -- Feature Negotiation!!!
	Every digital communication medium needs decent "feature
negotiation" to allow growth and upgrades, so that newer nodes can use
newer features without breaking older ones.  This is especially important
in Jabber since it's a completely open architecture, so special
transports, modules, and clients will be written with unique and special
feature sets.  All of these need to be able to negotiate with each other
what they all can/can't do.  Info queries with a <type>feature</type> can
be used everywhere to ask if the other side can do a certian feature or
ask for information about that feature.  Example: client to client file
transfer query might look like <info> <to>user</to>
<target>client</target> <type>feature</type>
<query><c2c_file_ssl/></query> </info> would ask the other client if they
can do SSL file transfers directly, and the client might(definately
optionally) respond with a
<result><c2c_file_ssl>123.23.12.231:8453</c2c_file_ssl></result>
signifying where to put the file. 



Obviously, this is a fairly important piece of Jabber.  I expect some
discussion on these subjects, but please, let's try to remember that we
want to keep the base protocol simple and any of these items as optional
as possible.  This won't be in 0.6 but will be added in shortly after.
Much of it needs to be fleshed out yet, primarily exactly what the common
public, admin, and feature queries are going to be.


Jer