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

[Vivre Draco]

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 
spelling/grammar corrections.  

   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
> variable. 

   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 
Sheppard</dogbreed><dogcolor>Blue... etc.

   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 
like...

dogbreed: German Sheppard
dogcolor: Blue
etc.

   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 
spelling/grammar corrections.

   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 
connection, too.

> 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/