[JDEV] File Transfer Proposals

[David Sutton]

chicken and egg .. sometimes you need to think about how something might
work to see what problems would occur. I want standardisation too.

* Offline support (pass as it stands offers no caching that I can see)
* Firewall support (example 2 users, 2 locations, same NAT'd ip address
range)
* 'Multicast' (single send, multiple receive)

David

On Sat, 2002-02-16 at 00:47, Julian Missig wrote:
> Long wordy replies like this are exactly what I'm trying to get away
> from. I want a quick, short bullet list of what's wrong with current
> stuff.
> 
> As far as I can tell, your entire message boils down to the "PASS
> doesn't allow more permanent file caching" -- the rest of it is about
> lack of standardization... which happens because no one is agreeing on
> how to do file transfer, which is what I will slowly get it.
> 
> I don't want suggested systems. I want to know what is wrong. In less
> than 50 words per point. Instead of many people posting many proposals,
> let's figure out what the problem is first.
> 
> Julian
> 
> On Fri, 2002-02-15 at 19:33, David Sutton wrote:
> > Hi all,
> > 
> >   I think part of the problem is that HTTP/FTP OOB + PASS is good up to
> > a point, but there needs to be an additional part, which is what I was
> > trying to address. I know of someone on the jdev conference area (I
> > think its Simon, but its late and i'm half asleep) who is using PASS for
> > streaming data. This is all fine and good for small things, but not
> > random files like many people on IMs like to throw at their contact list
> > .. and OOB would be the communication mechanism between the server
> > software and the clients, but I can see a lot of potential wastage of
> > bandwidth if thats all you use. Take the person who sends a file to 5
> > people all on the same jabber server .. only one upload was required if
> > you take a system like the one I suggested, and the users don't have to
> > be online. It keeps the files, which could be anything, seperate from
> > the users data on the jabber server. It gives a standard for other
> > people to work with. HTTP/FTP OOB as it stands basically says that i'm
> > going to somehow upload a file somewhere, and tell you where it is ..
> > what I'm trying for is saying 'where' the file is going, and how you can
> > go collect it.
> > 
> > The system I suggested would not be any good for things like streamed
> > voice or images, but then again, thats another reason for having PASS.
> > 
> > David
> > --
> > jid: peregrine at jabber.sys.legend.net.uk
> > 
> > ps: if you tried to add me in the last hour or two, I got the request,
> > but gabber nose-dived on me and I wasn't running in debug so don't have
> > your jid
> > 
> > -- rest of included message --
> > On Fri, 2002-02-15 at 23:47, Julian Missig wrote:
> > > On Fri, 2002-02-15 at 18:33, Julian Missig wrote:
> > > > A lot of people have been talking about all sorts of ways to do file
> > > > trasnfer. Before temas and I (and others) start working on making JEPs
> > > > out of the current file transfer implementations, I want to know what's
> > > > wrong with them.
> > > > 
> > > > So my question is: What is wrong with the current HTTP/FTP OOB + PASS
> > > > solution?
> > > > 
> > > > Currently the list is:
> > > > - limited to HTTP/FTP (need a better way to indicate protocols
> > > > supported, possibly browse?)
> > > > - PASS doesn't allow more permanent file caching
> > > > - lack of documentation
> > > > - lack of implementation
> > > 
> > > And before anyone says anything, by lack of implementation I mean that
> > > it's not extremely widely implemented, in fact I'm not aware of any PASS
> > > client implementations yet. However, jabber.org does have PASS support
> > > and some clients already do HTTP/FTP OOB.
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev