[JDEV] Proposals (file transfers and info/query)

[Jeremie]

> In a previous message your said your FTP proposal would handle the MIME
> situation. I don't see that is has; however, before I end up posting my MIME
> 6 page essay I'm asking the question if there is to be more posted soon on
> the subject? I wouldn't want to post duplicated information.

What specific MIME functionality is lacking that cannot be expressed via
normal HTTP/1.1 headers?  The proposal simply suggests that Jabber needn't
know anything internally about the resources being described by an HTTP
URL besides the URL itself, and that all other information about that
resource can be gathered via an HTTP HEAD request to the resource.

> A comment on Info/Query: You take the position that you don't want to waste
> the brain/manhours spend on currently existing protocols. I would like to
> place forward the suggestion that we create a Info/Query system very similar
> to LDAP, if not a direct mapping to Jabber's XML based protocol.

The problem here is multi-fold.  Besides placing an additional requirement
on the client for something that can be expressed and handled easily
within Jabber, using LDAP for info/query would severly limit it's
usefullness.  The info/query proposal isn't just for setting/querying user
information, but for also querying internal server data or setting
administrative variables.  For example, there might be a query to a Jabber
server that an administrator could make to return a list of all of the
current sockets to the server, or set the timeout threshold, or rotate log
files, etc.

Also, another VERY powerful aspect of the Info/Query proposal is the
client to client queries, where one client can send a query to another
client (it's ignored by the server and just passed on.).  This is what
would be used for feature negotiation, query another client for the
features that it supports.  It could also be used for specialized
applications such as a hardware device that is connected as a user
session, queries to it could return current information(position/location,
temperature, etc) or instruct it to do things.

I realize that there is overlap between the user information aspect of the
Info/Query proposal and existing LDAP functionality, but IMHO there is
lots of additional value in the proposal for other purposes.  As I've
mentioned before, if we just keep the client->server queries in the XML
stream, the server can(and will) have a mod_ldap that utilizes an LDAP
server in the background to manage the user information.  And of course,
this LDAP server should be queryable directly via LDAP for those that want
to access it directly.

Does this make sense, or am I flogging the wrong issue?

Jer