[JDEV] Proposals (file transfers and info/query)
jeremie at jabber.org
Tue Aug 10 09:11:01 CDT 1999
> Under <type>***</type>: private >>Priavte<< only data
> Immediately before discussion: "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)" -- It's my understanding that the grammatically correct way
> would be to remove the period from its current location and place it
> after the final parenthesis.
> Now, to the potentially more interesting parts...
> [snipped excellent discussion of discoverable queries]
This ran through my head some time ago but I forgot to include it in the
proposal... What I was thinking is that when an empty query was sent, a
reply of all of the possible fields would be returned:
Would be the "discovering" query, with a possible reply of:
Unless there is an issue with this, I'll add it to the proposal :)
For automated purposes though, I would still like to come to a consensus
on a standard set of queries for different purposes. So that for instance
clients could have a special "about" box for the server that would show
the common variables(url, admin name/email, etc), and those simple queries
would need to be hard-written into the client.
> > File Transfer Proposal: http://core.jabber.org/file.html
> Under HTTP: "Why not utilize all that has been invested in
> knowledge and development in HTTP for file transfers with Jabber?"
> That should be "of" HTTP, not "in" HTTP.
> Under How?: It's not as simple as just saying "Ok, we'll use
> HTTP". -- I believe the final " goes after the period. As for "the
> URL could be placed somewhere else in the message(possibly in the ext
> tags?).", I think you've been programming too much -- There's
> normally a space before a parenthesis.
> Under Sending Files: The same parenthsis-w/o-space problem occurrs
> several times in the last paragraph.
> Hrm I think allowing a description and address is definately a
> good idea. Requiring client parsing of say seems like a bad idea, as
> does including the URL in <ext> because, if I understand right,
> unrecognized content in <ext> wouldn't normally be shown to the user.
> Not sure what's a good idea, though...
Why not use the subject field then, the <sub>http://whatever</sub> would
be the "subject" of the message and the <say></say> would contain the
description. This way with clients that don't recognize the special
message, their users can still access and cut/paste the URL. This also
works well with transports to other IM services, who would all preserve
the subject even if they don't support the message type directly.
> Though this is designed for file transfer, I think it would work
> fine for negotiating *any* client-client connection. You might want
> to call it type=ctc (client to client) or something similar though,
> rather than "file" which could be confusing to developers and cause
> client-writers to create their own CTCP when they don't realize that
> "file" covers almost every other possible type of client-client
> connection, too.
Agreed. What about type='url'? This way any resources that can be
described via a URL (which is just about everything anymore and custom
uses can be of the format custom://server:port/resource) can be sent.
> I corrected the errors I saw, but didn't do a careful proof-
> reading. As far as the ideas behind the proposals, though, they both
> seem quite sound and no real problems come to my mind, just the
> couple minor suggestions mentioned above.
Thanks! Comments and corrections appreciated!
More information about the JDev