[JDEV] Proposals (file transfers and info/query)
cfc at paganpaths.org
Tue Aug 10 03:59:23 CDT 1999
On 10 Aug 99,, Jeremie sounded off on [JDEV] Proposals (file transfers an:
> Info/Query Proposal: http://core.jabber.org/info.html
Note: Potentially more interesting comments follow the
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...
> Servers and transports should be required to provide a standard
> set of public queryable variables such as help, register, admin,
> about, url, which return user-readable information about the
I suggest allowing a client to request a list of available, filled
out information fields on a particular person/client/server, rather
than having to know what the standard set is and request them
indiviually. This has several advantages... First, it allows simpler
clients, as they don't have to store a list of standard fields to
request, but can simply ask what fields are available then request
them all (maybe even just request "all available info fields" on X).
Also, in addition to a standard set (which may not even be necessary,
though would probably be nice for the sake of consistency),
people/client/servers could add any number of custom information
fields they wanted and still have other people actually SEE the info
w/o their client requiring special support (see below). That way, if
Joe wants to make sure everyone knows the breed, color, name, and URL
of a picture of his dog, he can <set><dogbreed>German
As far as rendering in the client, they can have special rendering
for recognized info fields if they want, but could always render any
unrecognized fields simply as "field name: field content." E.G., in
the above example you might request info on Joe and see something
dogbreed: German Sheppard
While this has obvious potential for abuse (a user putting a
billion fields in its info so when another user requests info on that
user they get flooded, or just wasting server space), each server
could set a limit on numbers of fields that it would allow to be
stored for each of its users, and/or a limit on size/type of the
content of each field, plus any given client could set an upper limit
on how many fields of info it'll request from the list of available
info fields, and/or could just request a set of standard ones and not
even request a list of what's available. Or it could show the list of
what info's available to the user and let the user choose which to
request, or... etc.
Also, though I imagine when I read your FT Proposal some light
will be shed on the details of this, I imagine that you could
actually include your dog's picture and a recording of him barking in
your info if you wanted to...
> File Transfer Proposal: http://core.jabber.org/file.html
Note: Potentially more interesting comments follow the
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.
> what if the sending user wanted to also include a description of
> the download? Two possibilities, the say field could include the
> description AND URL and the client software would have to scan and
> parse out the URL, or as another option, the URL could be placed
> somewhere else in the message(possibly in the ext tags?). This
> needs some discussion.
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...
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
> Warning: I just finished writing these and am not all that awake
> at the moment. I haven't even gone back over them for a sanity or
> spelling check, so expect grammatical and other errors.
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.
You may be addicted to the Net when...
You step out of your room and realize that your parents
have moved and you don't have a clue when it happened.
Copyright 1999 Vivre Draco (cfc at paganpaths.org)
excelsior ad infinitum -- http://www.paganpaths.org/~cfc/
More information about the JDev