Hello Matthew, thanks for the feedback.

On 11/05/2012 11:06 PM, Matthew Wild wrote:
Hi Jefry,

On 6 November 2012 01:19, Jefry Lagrange<jefry.re...@gmail.com>  wrote:
Hello,

I've been working for quite some time in a protocol extension to allow file
sharing. I have a (some-what) working prototype of its implementation.
Great to hear! I can think of a million-and-one uses for such a
protocol, and I'm sure I'm not alone.

The prototype is available at Gajim's plugin repository:
http://hg.gajim.org/gajim-plugins
and running code is always good :)

I read very quickly through (it's 4am after all...), and it seems
pretty sensible. Any comments I have are minor, and I think it's
perfectly fine to submit it as it is.

A few of my comments...

It seems like it might be possible to make the directory listing XML
somewhat more compact than it currently is. For example just listing
files with no metadata could simply be:

    <file name="foo.txt"/>
    <file name="bar.txt"/>

which seems a lot simpler than the nested XML elements in the example.
Metadata can be child elements of<file/>  because although every file
has a name, metadata may vary and will almost certainly want to be
extended in some cases.
Yeah, about that... I wanted to reuse current extensions whenever possible. This format for <file> is the same in xep096 and xep234. I see what you are saying, it is indeed more compact and saving bandwidth in a situation where big stanzas are sent, is very important.

At first I considered the dataforms as they are used in xep0135, but they were too big to be used efficiently. I definitely favor making this as compact as possible.
I'm not sure how necessary it is to require the leading '/' prefix, it
seems natural to omit it if I just have a flat list of files. And then
'foo/bar.txt' is perfectly fine when I don't, so it seems like it
could be dropped without much problem.
Does it look weird? The only reason why I made it a requirement to use a leading '/' was to make it possible to distinguish between asking for more information on a file or directory, and searching for a file. When searching files there should not be a "/" prefix. I don't know of any other way of doing this.

Dataforms would be very good for searching, since they support regular expressions. However, as I said before, they can get pretty big.

I would like to listen to some ideas about how search could be accomplished in a nice way.


The security note about access control being implemented on servers
doesn't make complete sense. Files are shared by a specific resource,
so each resource can enforce its own access controls... and different
resources won't necessarily be sharing the same sets of files. A
logged in client generally already has the roster, which is probably
the main access control advantage that the server could offer anyway.

Ah... I didn't make it clear. What I was thinking about was not about individual file permissions, it was about preventing an user to see any files at all. Blocking an user from file sharing, would require agreement across the different resources so they can agree about no sharing files with that particular user.

I know realize that this is more of an implementation issue than a security issue, I should move it to "implementation notes", because it is up to the implementers if they want to add a feature to block an user from all file sharing.


Anyway, good work... and I look forward to it being approved soon, and
perhaps implementing it myself :)

Regards,
Matthew

Thanks.

Reply via email to