[dcc2] Multi file sends

[Dan Smith]

At 11:27 PM 4/26/2004 -0400, you wrote:
>Yes, I was looking at the other one.
>
>In that case, regarding the (relative) paths, why?  So the person sending
>the file can suggest the path it belongs to for the receiving party
>(relative to the receiving party's base download directory)?  I can't think
>of any other reason its there.
>
>If that is the reason, can I ask why anyone would want that?

Hi Tom!  Sorry it took so long to get your email subscription sorted out :)

When sending multiple files, relative paths are needed to guarantee 
filename uniqueness.  Think of multi file sends like a GNUtar archive, the 
xml (or whatever format we decide upon) is the header.  Relative paths 
should not present any security issues that can not be easily checked and 
overcome by implementers.


About XML versus "Another text format"

I personally think XML is a perfect format for describing this information 
due to its ubiquitous presence on all platforms, and it's maturity.  XML is 
easily transported between applications and that can lead to synergy 
between IRC file transfers and other types of applications.  Why invent our 
own format and require every one who wants to interact with multi transfers 
to implement a "multi file transfer parser"?

Discussion of possible bugs in various xml parsers is not advancing this 
discussion.  I think it is more likely for coding problems arising in 
custom string parsing than by using xml api's, but of course this is just a 
personal opinion.

For a token based system, I think a listing using a format similar to http 
headers could work.  A single name-value pair could be present on each 
line.  Multiple files could be separated by a double new line, much like 
http headers from content.

fileid : 1
name : somefilename.ext
desc : a file

fileid : 2
....

Drawbacks to this approach is that XML is a hierarchical data format, while 
tokens are always limited to name-value pairs.  As we expand the metadata, 
we may find ourselves working harder to overcome this lacking.  Secondly, 
each author must write a custom parser for this format.  Altho I discourage 
a token based system, I realize some people do not want to add additional 
dependances to their application.  Is this enough of a reason to not use 
xml in our specification?  Perhaps, what are your opinions?

Cheers!
Dan



---------------------------
Dan Smith
+1 608-213-2867
Algenta Technologies, LLC