osw-android and upload of pictures

[Luca Faggioli (Openliven)]

Hi all!

I just noticed that the upload of pictures is not implemented in the
OSW Android app: any specific reason why is not there or is that just
a feature waiting for someone to pick it up and implement it?

thanks!
luca

P.S.: BTW, OneSocialWeb is No. 33 of the 100 Things to Watch in 2001
(slide 42) http://www.slideshare.net/jwtintelligence/2f-100-things-to-watch-in-2011-6306251

[Laurent Eschenauer]

> I just noticed that the upload of pictures is not implemented in the
> OSW Android app: any specific reason why is not there or is that just
> a feature waiting for someone to pick it up and implement it?

Yes. Uploading requires the discovery of the HTTP endpoint where to
upload. You could use a convention but it won't work everytime
(especialy for xmpp domains that need DNS SRV for resolution of the
XMPP host). Thus, one need first to add a XMPP Disco layer to
discover the relevant endpoint from the host. This is not difficult,
just need to be done.

In the web world, it was easier, since you can provide the endpoint
through configuation of the web client server side.

if you go ahead, I would suggest to think through XMPP Disco
(XEP-0030) as it is much a needed layer for the whole protocol anyway.
Adding disco could enable decoupling of some of the endpoints; thus
enabling implementations over the component protocol.

Hope it helps,

Laurent

Hope it helps,

Laurent

[Luca Faggioli]

Hi Laurent,

I thought it would be fair to have http://<domain>/file as endpoint like it is in the index.html of the web-console, since I don't think many would change the suggested configuration on the server side (proxy and stuff like that), but, as you pointed out, that's not enough...

If I implement Disco in the plugin, the file_retrieval_endpoint should be entered manually in some sort of config file, shouldn't it? I mean: there's no way the plugin would know that value, since it depends on the proxy configuration under apache, correct?

Thanks a lot!
luca

2011/1/4 Laurent Eschenauer <laurent.e...@gmail.com>

--
Luca Faggioli
OneSocialWeb JID: lu...@social.openliven.com

[Laurent Eschenauer]

> I thought it would be fair to have http://<domain>/file as endpoint like it
> is in the index.html of the web-console, since I don't think many would
> change the suggested configuration on the server side (proxy and stuff like
> that), but, as you pointed out, that's not enough...

Indeed. For example: the vodafone accounts are @vodafonernd.com, but
the host (and thus the HTTP endpoint for uploading) is
osw.vodafonernd.com (discovered via DNS SRV in the XMPP world). Domain
does not always imply web host (or you force a convention that the
host osw.domain should always exist).

> If I implement Disco in the plugin, the file_retrieval_endpoint should be
> entered manually in some sort of config file, shouldn't it? I mean: there's
> no way the plugin would know that value, since it depends on the proxy
> configuration under apache, correct?

Correct. There are already other parameters that can be configured in
the plugin, using the regular openfire config screens. Lookup for the
upload folder for example, it can be user configured:
https://github.com/onesocialweb/osw-openfire-plugin/blob/master/src/java/org/onesocialweb/openfire/web/FileServlet.java#L240

>
> Thanks a lot!

Happy to help :-)

Cheers,

Laurent

[Daniel Renfer]

I think what we need is a XRD over Pubsub spec. That way, hybrid
social networks can simply serve the same document for users both ways
and any enhancement in the webid space will also apply to the XMPP
side.

[Luca Faggioli (Openliven)]

Hi Daniel,

considering also what you posted in OSW, I'm not quite getting how I
could include the HTTP end-point in the host-meta, when what the
client is trying to discover is not only the upload "folder", but also
the host itself...

Am I missing something?

Thanks a lot!
luca

On Jan 4, 3:28 pm, Daniel Renfer <d...@kronkltd.net> wrote:
> I think what we need is a XRD over Pubsub spec. That way, hybrid
> social networks can simply serve the same document for users both ways
> and any enhancement in the webid space will also apply to the XMPP
> side.
>
> On Tue, Jan 4, 2011 at 8:59 AM, Laurent Eschenauer
>

> <laurent.eschena...@gmail.com> wrote:
> >> I thought it would be fair to have http://<domain>/file as endpoint like it
> >> is in the index.html of the web-console, since I don't think many would
> >> change the suggested configuration on the server side (proxy and stuff like
> >> that), but, as you pointed out, that's not enough...
>
> > Indeed. For example: the vodafone accounts are @vodafonernd.com, but
> > the host (and thus the HTTP endpoint for uploading) is
> > osw.vodafonernd.com (discovered via DNS SRV in the XMPP world). Domain
> > does not always imply web host (or you force a convention that the
> > host osw.domain should always exist).
>
> >> If I implement Disco in the plugin, the file_retrieval_endpoint should be
> >> entered manually in some sort of config file, shouldn't it? I mean: there's
> >> no way the plugin would know that value, since it depends on the proxy
> >> configuration under apache, correct?
>
> > Correct. There are already other parameters that can be configured in
> > the plugin, using the regular openfire config screens. Lookup for the
> > upload folder for example, it can be user configured:

> >https://github.com/onesocialweb/osw-openfire-plugin/blob/master/src/j...

>
> >> Thanks a lot!
>
> > Happy to help :-)
>
> > Cheers,
>
> > Laurent
>
> >>> In the web world, it was easier, since you can provide the endpoint
> >>> through configuation of the web client server side.
>
> >>> if you go ahead, I would suggest to think through XMPP Disco
> >>> (XEP-0030) as it is much a needed layer for the whole protocol anyway.
> >>> Adding disco could enable decoupling of some of the endpoints; thus
> >>> enabling implementations over the component protocol.
>
> >>> Hope it helps,
>
> >>> Laurent
>
> >>> Hope it helps,
>
> >>> Laurent
>
> >> --
> >> Luca Faggioli

> >> OneSocialWeb JID: l...@social.openliven.com

[Daniel E. Renfer]

Basically, what XRD / Webfinger does is allows a host to provide a
series of links to services it provides. The file upload endpoint could
be considered one of those services. There would need to be a new type
of relation stating that a given HTTP url accepts files to be posted to
it and returns some sort of information. (I don't know how the file
upload mechanism works currently)

So what a client would do is connect to it's host. (ie
social.openliven.com) and request the XRD document from the "host-meta"
pubsub node. This document could then be parsed to determine that
social.openliven.com accepts files to be posted to
http://social.openliven.com/file.

It's really only a half-baked idea, but it should be relatively simple
to parse these document and standard pubsub should be enough to support
this in most cases.

Since XMPP already has mechanisms for locating resources associated with
a user, the host-meta parsing part could be skipped when trying to find
the user's webfinger document. Just get the 'user-meta' PEP node and
you're good to go.

Make more sense, or is there still something that one or the other of us
is missing?

[Luca Faggioli]

ok, thanks Daniel, it's somehow a little bit more clear

I'll try to have a deeper look at it as soon as I have some spare time

talk to you soon
luca

2011/1/12 Daniel E. Renfer <duck1...@gmail.com>

--
Luca Faggioli
OneSocialWeb JID: lu...@social.openliven.com