[dcc2] Multi file sends

[Tom McAlee]

Hi Dan.  Regarding this comment...

> 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"?

I don't know if you've experienced this with dIRC or not, but I sure have
with Klient: many people judge an IRC client more by its size and/or the
size of its download than they do by the features in the client itself.

Personally, provided it was full of functionality and not bloat, I'd love to
see what a 30mb IRC client had to offer.  But, many people don't feel that
way.  Yes, it is kind of rediculous... many IRCers have a couple of hundred
gigs of hard drive space free and hundreds of mb of ram, but complain when
an IRC client uses more than 3mb on the hard drive, more than 5mb of ram, or
causes their system to use more than 5% of its CPU while their other
applications are running.

Many people simply won't even download it to even try it out.  I've even had
network admins tell me that while they liked the features, they definately
would not be recommending it because they would never recommend an IRC
client that is 5mb in size.

I'm not saying I agree with their method of assessment, but that is the sad
fact.  If a client doesn't already use XML parsing for anything, adding the
libraries for it could add quite a bit onto the size of the executable.  I
try to squeeze out every kb I can, so I for one would prefer text-based
parsing unless the XML parsing is actually going to buy me something in
terms of features.  If it isn't giving any new features and only saves
having to do a little parsing, it doesn't seem worth the cost.

Tom

----- Original Message ----- 
From: "Dan Smith" <dan at algenta.com>
To: "DCC2 Working Group List" <dcc2 at dcc2.org>
Sent: Tuesday, April 27, 2004 12:04 AM
Subject: Re: [dcc2] Multi file sends


> 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
>
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
>