[Standards] File hosting XEP?

jefry.reyes at gmail.com jefry.reyes at gmail.com
Wed Aug 15 14:15:16 UTC 2012


I deem blogging a necessary feature and I want to implement it (show me  
your client I would like to see how you are doing). Thinking about the  
implementation the subject of attaching files came up and Out of Band data  
transfer looked like the best solution.

There are a lot of benefits to Out of Bound:

* You don't have to modify existing servers (this is a big plus!)

* You get to use existing file hosting services (there are a lot and can  
provide for more space than xmpp servers)

* You don't have to introduce a new XEP


I just don't see how is it that your users will be locked out in your  
implementation. When they upload files and make their posts, their friends  
will be able to read them and download the file using xep-66 and xep-277  
which are XMPP technologies.

They would be locked out if in order to download the file they have to  
implement some non-xmppp technology, but that's not the case. They can get  
it and read it. So I don't see or understand what you are saying.

On , Sergey Dobrov <binary at jrudevels.org> wrote:
> On 08/14/2012 11:53 PM, Jefry Lagrange wrote:

> >> Sure, but how client will upload it's attachments? I can do it in a

> >> client-specific way, but then others will not be able to implement the

> >> same thing.

> >

> >

> > If I understand correctly, what you want to do is to attach files to a

> > microblog post. Since you can use Out of Band Data for that, you can

> > upload the file out of band without the need of xmpp eg uploading it

> > to an FTP.



> How client would know which FTP server it should use and which HTTP link

> it should use then to use in a content? That's a suitable way for

> centralized services with proprietary clients but if we want to make

> possible to write your own client we must specify such things, and the

> best way, as I consider, is to use XMPP-based protocol to serve files.



> >

> > True, the client has to be modified to support this, but since it

> > isn't covered in any XEP afaik, you would have to modify it anyway.



> That will lead users to lock in my implementation.



> >

> > Therefore, your client will be able to upload files while other

> > clients will not until their devs deem it a necessary feature.



> Obviously, but the problem is a little wider: devs have to deem blogging

> as a necessary feature, which is an another situation.



> >

> > On Tue, Aug 14, 2012 at 9:04 AM, Sergey Dobrov binary at jrudevels.org>  
> wrote:

> >> On 08/14/2012 07:47 PM, Todd Herman wrote:

> >>>> -----Original Message-----

> >>>> From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org]  
> On Behalf Of Sergey Dobrov

> >>>> Sent: Tuesday, August 14, 2012 4:44 AM

> >>>> To: standards at xmpp.org

> >>>> Subject: [Standards] File hosting XEP?

> >>>>

> >>>> Hello all, hope you are all good.

> >>>>

> >>>> Me and Jaussoin Timothée faced with a problem to attach files to  
> microblog posts. The easier way to do that is to serve files somewhere  
> and link to them from the posts. >But what is the appropriate way to do  
> that?

> >>>

> >>> Having files somewhere and linking to them sounds a lot like  
> Out-Of-Band Data (XEP-0066). It covers the linking part (mainly used in  
> SI File Transfers and Message stanzas) and leaves the transferring of the  
> files and how they are stored on the server to you.

> >>

> >> Sure, but how client will upload it's attachments? I can do it in a

> >> client-specific way, but then others will not be able to implement the

> >> same thing.

> >>

> >>

> >> --

> >> With best regards,

> >> Sergey Dobrov,

> >> XMPP Developer and JRuDevels.org founder.

> >>

> >

> >

> >





> --

> With best regards,

> Sergey Dobrov,

> XMPP Developer and JRuDevels.org founder.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120815/3a32702f/attachment.html>


More information about the Standards mailing list