Re: buddycloud call tonight.

[Simon Tennant (buddycloud)]

Hi Rodrigo.

Thanks for the update.

Let's think a little about how the endpoints should lookto make sense to developers. We want something that is clean and predictable. We also need a nice way to handle "special" media like avatars. Additionally we need to be able to query for a size of media to be returned (we don't want a mobile phone receiving a 3MB avatar).

Here's my proposal for how our endpoints could look:

• /media (we place anything to do with media under this endpoint (the HTTP server will just proxy anything to the media server)
• /media/<chann...@domain.com>
  • POST new media to a channel
    • returns the new mediaID and checksum on completed upload
  • GET a list of all media in a channel
• /media/<chann...@domain.com>/<mediaID>
  • GET an existing media file with this endpoint
  • how do we call back the existing media vs a thumbnail or resized version?
  • PUT,DELETE exisiting media by posting back to this endpoint
• /media/<chann...@domain.com/1
  
  • a mediaID of "1" is always the avatar.
  • only the channel producer and moderators can update mediaID with update a channels metadata (moderators and producer), only users with this role can update this metadata

Any thoughts on this layout and on how we get back thumbnails for any media?

S.

 

 

On Mon, 28 May 2012 15:59:02 -0300, Rodrigo Duarte <rodrig...@gmail.com> wrote:

Here is my progress last week

- say what you have done:

Implemented the download method, and also, added resources to handle requests to avatars. Like the proposed idea, all avatars have id = 1, in this way, the urls are:

GET/PUT /channel/{channelId}/media/avatar/1

GET/PUT /user/{userId}/media/avatar/1

- bottlenecks you face:

Just lack of time, in last week and this one, I'm having a lot of things to do at the same time, so my productivity is in a low level.

- what you plan to work on next week:

Finish the avatar handling (with tests) and start the development of the xmpp component.

Unfortunately, I have to do a project for the msc and it conflicts with our meeting. Can you share this with the other bc members? Any doubts or suggestions you can send me via email and I'll try to reply later =)

On Mon, May 21, 2012 at 3:36 PM, Rodrigo Duarte <rodrig...@gmail.com> wrote:

Hi Simon,

Since I'll not be able to talk during the meeting, here is some points about the topic that you requested:

On Mon, May 21, 2012 at 10:55 AM, Simon Tennant <si...@buddycloud.com> wrote:

We have two calls tonight.

8pm: normal bc call.

9pm: GSOC call.

Let's keep then short and to the point:

- say what you have done,

Made some initial documentation to support the first steps development and also, commited some code, with upload files functionallity.

To upload a file, the client must send a multipart/form-data, with two fields (more fields for authentication can be added later): a file description in json and the file itself (binary).

The file description was based on the google drive API:

{

  "id": string,

  "uploader": string,

  "title": string,

  "mimeType": string,

  "description": string,

  "uploadedDate": datetime,

  "lastViewedDate": datetime,

  "downloadUrl": string,

  "fileExtension": string,

  "md5Checksum": string,

  "fileSize": long,

  "length": long,

  "resolution": string

}

Attributes like "downloadUrl" is added by the server during the storing metadata process. md5 and fileSize are utils for client and server media integrity verification.

I also made a test where a client is started and it successfully uploads a file.

 

- bottlenecks you face

Is more a doubt about server side media handling: When an user uploads a video, the client should provide "resolution" and "length", in this way, the server should verify if the media uploaded is really a video with the provided properties? Maybe it adds some computation that would slow down the server.

 

- what you plan to work on next week.

I'm planning to finish the upload and download methods (without authentication) in the next two weeks, for the next few weeks work on the xmpp side. Everything with tests, of course, of each success and fail scenario (for example, try to upload an empty file - size 0, etc).

I also need to close some issues that I've opened last week at github.

 

Please update your Trello bits before the call so we keep it structured.

And we push all architecture bits to the mailing list/appropriate channel.

See you at 8 or 9.

S.

--
Rodrigo Duarte Sousa
MSc candidate in Computer Science

Distributed Systems Laboratory
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://lsd.ufcg.edu.br/~rodrigods

--
Rodrigo Duarte Sousa
MSc candidate in Computer Science

Distributed Systems Laboratory
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://lsd.ufcg.edu.br/~rodrigods

 

-- 
Simon Tennant
si...@buddycloud.com

mobile: +49 17 8545 0880
office: +44 20 7043 6756 
office: +49 89 4209 55854

[Kirk Bateman]

Morning all,

It might be worth looking into the oembed.com OEmbed spec to see if there is anything particularly relating to thumbnails that can be "appropriated" :)

Cheers

Kirk

[Simon Tennant (buddycloud)]

Very good point Kirk. We should make sure to return oembed bits for any object. Oembed also has some good ideas on the thumbnail requests:

width (required)

The width in pixels of the image specified in the url parameter.

height (required)

The height in pixels of the image specified in the url parameter.

Responses of this type must obey the maxwidth and maxheight request parameters.

We should make sure to support this with our thumbnail and image requests.

 

S.

 

On Thu, 31 May 2012 10:40:10 +0100, Kirk Bateman <kirk.b...@gmail.com> wrote:

Morning all,

It might be worth looking into the oembed.com OEmbed spec to see if there is anything particularly relating to thumbnails that can be "appropriated" :)

Cheers

Kirk

On 31 May 2012 10:37, Simon Tennant (buddycloud) <si...@buddycloud.com> wrote:

Hi Rodrigo.

Thanks for the update.

Let's think a little about how the endpoints should lookto make sense to developers. We want something that is clean and predictable. We also need a nice way to handle "special" media like avatars. Additionally we need to be able to query for a size of media to be returned (we don't want a mobile phone receiving a 3MB avatar).

Here's my proposal for how our endpoints could look:

• /media (we place anything to do with media under this endpoint (the HTTP server will just proxy anything to the media server)
• /media/<chann...@domain.com>
  • POST new media to a channel
    • returns the new mediaID and checksum on completed upload
  • GET a list of all media in a channel

• /media/<chann...@domain.com>/

[Rodrigo Duarte]

Hi,

Everything looks great! Just little thoughts:

We can have a similar approach to get the avatars:

/media/<chann...@domain.com>/avatar

• POST new avatar
  • returns the json representation of a media, that includes new mediaID, checksum, etc on completed upload
• GET the json media representation of the current avatar (includes mediaId, height, width, checkum, etc)

/media/<chann...@domain.com>/avatar/{mediaId}/{maxHeight}/{maxWidth}

• PUT avatar
• updates current avatar
• GET 
• Here, the client has the option of passing maxHeight and maxWidth, so... The server verifies if this media has a preview with those specifications, if not, it creates one, stores it and sends to the client. We can use the same approach for regular media.

What do you think?

[Tuomas Koski]

Hi,

(these discussions on the channels ;) )

On 31 May 2012 11:37, Simon Tennant (buddycloud) <si...@buddycloud.com> wrote:
> Additionally we need to be
> able to query for a size of media to be returned (we don't want a mobile
> phone receiving a 3MB avatar).

Client could use HEAD HTTP method request for that.

Or we could support some short of "Max-Content-Length" -header in the
GET request.

On 31 May 2012 11:37, Simon Tennant (buddycloud) <si...@buddycloud.com> wrote:
> /media/<chann...@domain.com/1
>
> a mediaID of "1" is always the avatar.

Why not just /media/<chann...@domain.com/avatar ?


Cheers,
--
tuomas

[Tuomas Koski]

Hi,

On 31 May 2012 12:59, Rodrigo Duarte <rodrig...@gmail.com> wrote:
> We can have a similar approach to get the avatars:
>
> /media/<chann...@domain.com>/avatar
>
> POST new avatar
>
> returns the json representation of a media, that includes new mediaID,
> checksum, etc on completed upload
>
> GET the json media representation of the current avatar (includes mediaId,
> height, width, checkum, etc)
>
> /media/<chann...@domain.com>/avatar/{mediaId}/{maxHeight}/{maxWidth}
>
> PUT avatar
>
> updates current avatar
>
> GET
>
> Here, the client has the option of passing maxHeight and maxWidth, so... The
> server verifies if this media has a preview with those specifications, if
> not, it creates one, stores it and sends to the client. We can use the same
> approach for regular media.
>
> What do you think?

Does that mean that for me to get pam...@playboy.com avatar, i need to
do two request to be able to display it? (1. get json with media ID,
2. get the real image)

Avatar fetching is so common that I would like to be able to do it
with one request.


Cheers,
--
Tuomas

[Simon Tennant (buddycloud)]

Agreed. For that to wrok we probably need to make sure that all avatars
are a know format like PNG (which makes sense).

S.

On Thu, 31 May 2012 13:45:40 +0200, Tuomas Koski <koski....@gmail.com>
wrote:

[James Tait]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31/05/12 12:40, Tuomas Koski wrote:
> On 31 May 2012 11:37, Simon Tennant (buddycloud)
> <si...@buddycloud.com> wrote:
>> Additionally we need to be able to query for a size of media to
>> be returned (we don't want a mobile phone receiving a 3MB
>> avatar).
>
> Client could use HEAD HTTP method request for that.
>
> Or we could support some short of "Max-Content-Length" -header in
> the GET request.

My concern here would be DOS attacks. A client issuing thousands of
HEAD requests for different combinations of image dimensions would get
very small chunks of data back, but cause the server to perform lots
of image processing work to be able to calculate the content length.

> On 31 May 2012 11:37, Simon Tennant (buddycloud)
> <si...@buddycloud.com> wrote:
>> /media/<chann...@domain.com/1
>>
>> a mediaID of "1" is always the avatar.
>
> Why not just /media/<chann...@domain.com/avatar ?

+1 to that. /avatar is understandable even to someone not familiar
with the project. "1" is more like a magic number that only has
meaning if you've read the code/specs.

JT
- --
- ---------------------------------------+--------------------------------
James Tait, BSc | xmpp:jayt...@wyrddreams.org
Programmer and Free Software advocate | Tel: +44 (0)870 490 2407
- ---------------------------------------+--------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/HW0AACgkQyDo4xMNTLiYZTQCggVP6YkdiSIxyYq09+fNl4owl
IAwAniF7hvo5NY9SrSDfU9Rsr4/c+Fp9
=JEe9
-----END PGP SIGNATURE-----

[Rodrigo Duarte]

Agreed for the "one" GET request approach =)

So...

GET, PUT, POST /media/<no...@domain.com>/avatar

With the well known operations for each method?

(remembering that GET avatar operations should be public)

--

Rodrigo Duarte

[Simon Tennant]

How does a service like flickr deal with DOS attacks like this?

S.

[Kirk Bateman]

The usual sort of ways I suspect, firewall rules, api request limits, rate limiting...

Cheers

Kirk

[James Tait]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31/05/12 13:20, Simon Tennant wrote:
> How does a service like flickr deal with DOS attacks like this?

As far as I know, Flickr only offers predetermined image sizes. For
example, if you look at:

http://www.flickr.com/photos/33076522@N08/7301025300/sizes/l/

Then the sizes listed are:

Square 75 (75 x 75)
Square 150 (150 x 150)
Thumbnail (100 x 67)
Small 240 (240 x 160)
Small 320 (320 x 213)
Medium 500 (500 x 333)
Medium 640 (640 x 427)
Medium 800 (800 x 534)
Large 1024 (1024 x 683)
Large 1600 (1600 x 1067)
Large 2048 (2048 x 1365)

I guess this means they can precompute the images as soon as they're
uploaded, or on demand if someone requests a size that hasn't been
rendered yet. I'm not sure how they deal with the differing source
image sizes though - it doesn't make much sense to me to offer an 8x8
icon in 2048x1365 pixels, for example.

JT
- --
- ---------------------------------------+--------------------------------
James Tait, BSc | xmpp:jayt...@wyrddreams.org
Programmer and Free Software advocate | Tel: +44 (0)870 490 2407
- ---------------------------------------+--------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/HbpMACgkQyDo4xMNTLiYeeQCfTBtMaOwQfheC+Pqg8gPYSGh8
8IkAn1w/G8fVW9AwyZBtSgejLjYfmayi
=64Bq
-----END PGP SIGNATURE-----

[imaginator]

I've written up this: https://buddycloud.org/wiki/Buddycloud_HTTP_API#.2Fmedia.2Fname.40example.com.2FmediaID

• How do we implement oEmbed discoveryon this endpoint?
  

Am I correct that the process to return an avatar will be:

• SRV lookup for API endpoint for domain
• HTTPS connect to remote API
• GET /media/fri...@remotedomain.com/avatar/64x64
• a 64x64 png arrives.
  

This will be done a lot in clients.... we should make sure it's optimised and we don't have extra roundtrips where necessary.

@james: I agree it makes no sense to be doing stretching on small images. But...

• What happens when a client has a user upload their avatar and it's 128x56 pixesl? What do we return when "...avatar/64x64" is requested ?

S.

On Thursday, 31 May 2012 11:37:20 UTC+2, imaginator wrote:

Hi Rodrigo.

Thanks for the update.

Let's think a little about how the endpoints should lookto make sense to developers. We want something that is clean and predictable. We also need a nice way to handle "special" media like avatars. Additionally we need to be able to query for a size of media to be returned (we don't want a mobile phone receiving a 3MB avatar).

Here's my proposal for how our endpoints could look:

• /media (we place anything to do with media under this endpoint (the HTTP server will just proxy anything to the media server)
• /media/<chann...@domain.com>
  • POST new media to a channel
    • returns the new mediaID and checksum on completed upload
  • GET a list of all media in a channel
• /media/<chann...@domain.com>/<mediaID>
  • GET an existing media file with this endpoint
  • how do we call back the existing media vs a thumbnail or resized version?
  • PUT,DELETE exisiting media by posting back to this endpoint

• /media/<channelname@domain.com/1
  

On Thursday, 31 May 2012 11:37:20 UTC+2, imaginator wrote:

Hi Rodrigo.

Thanks for the update.

Let's think a little about how the endpoints should lookto make sense to developers. We want something that is clean and predictable. We also need a nice way to handle "special" media like avatars. Additionally we need to be able to query for a size of media to be returned (we don't want a mobile phone receiving a 3MB avatar).

Here's my proposal for how our endpoints could look:

• /media (we place anything to do with media under this endpoint (the HTTP server will just proxy anything to the media server)
• /media/<chann...@domain.com>
  • POST new media to a channel
    • returns the new mediaID and checksum on completed upload
  • GET a list of all media in a channel
• /media/<chann...@domain.com>/<mediaID>
  • GET an existing media file with this endpoint
  • how do we call back the existing media vs a thumbnail or resized version?
  • PUT,DELETE exisiting media by posting back to this endpoint

• /media/<channelname@domain.com/1
  

On Thursday, 31 May 2012 11:37:20 UTC+2, imaginator wrote:

Hi Rodrigo.

Thanks for the update.

Let's think a little about how the endpoints should lookto make sense to developers. We want something that is clean and predictable. We also need a nice way to handle "special" media like avatars. Additionally we need to be able to query for a size of media to be returned (we don't want a mobile phone receiving a 3MB avatar).

Here's my proposal for how our endpoints could look:

• /media (we place anything to do with media under this endpoint (the HTTP server will just proxy anything to the media server)
• /media/<chann...@domain.com>
  • POST new media to a channel
    • returns the new mediaID and checksum on completed upload
  • GET a list of all media in a channel
• /media/<chann...@domain.com>/<mediaID>
  • GET an existing media file with this endpoint
  • how do we call back the existing media vs a thumbnail or resized version?
  • PUT,DELETE exisiting media by posting back to this endpoint

• /media/<channelname@domain.com/1
  

On Thursday, 31 May 2012 11:37:20 UTC+2, imaginator wrote:

Hi Rodrigo.

Thanks for the update.

Let's think a little about how the endpoints should lookto make sense to developers. We want something that is clean and predictable. We also need a nice way to handle "special" media like avatars. Additionally we need to be able to query for a size of media to be returned (we don't want a mobile phone receiving a 3MB avatar).

Here's my proposal for how our endpoints could look:

• /media (we place anything to do with media under this endpoint (the HTTP server will just proxy anything to the media server)
• /media/<chann...@domain.com>
  • POST new media to a channel
    • returns the new mediaID and checksum on completed upload
  • GET a list of all media in a channel
• /media/<chann...@domain.com>/<mediaID>
  • GET an existing media file with this endpoint
  • how do we call back the existing media vs a thumbnail or resized version?
  • PUT,DELETE exisiting media by posting back to this endpoint

• /media/<channelname@domain.com/1
  

On Thursday, 31 May 2012 11:37:20 UTC+2, imaginator wrote:

Hi Rodrigo.

Thanks for the update.

Let's think a little about how the endpoints should lookto make sense to developers. We want something that is clean and predictable. We also need a nice way to handle "special" media like avatars. Additionally we need to be able to query for a size of media to be returned (we don't want a mobile phone receiving a 3MB avatar).

Here's my proposal for how our endpoints could look:

• /media (we place anything to do with media under this endpoint (the HTTP server will just proxy anything to the media server)
• /media/<chann...@domain.com>
  • POST new media to a channel
    • returns the new mediaID and checksum on completed upload
  • GET a list of all media in a channel
• /media/<chann...@domain.com>/<mediaID>
  • GET an existing media file with this endpoint
  • how do we call back the existing media vs a thumbnail or resized version?
  • PUT,DELETE exisiting media by posting back to this endpoint

• /media/<channelname@domain.com/1
  

[James Tait]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31/05/12 14:56, imaginator wrote:
> @james: I agree it makes no sense to be doing stretching on small
> images. But...
>

> * What happens when a client has a user upload their avatar and

> it's 128x56 pixesl? What do we return when "...avatar/64x64" is
> requested ?

Well, I think in the Flickr instance they just wouldn't make that size
available - they don't allow you to specify arbitrary image
dimensions. There's an API method flickr.photos.getSizes [0] that
returns the sizes available for a given image, with dimensions and
URIs in the response. You get the photo ID from
flickr.people.getPhotos [1], and you can construct the photo URIs
yourself with the results from that call [2] - part of the URI spec is
a suffix (m|s|t|z|b) indicating the size.

[0] http://www.flickr.com/services/api/flickr.photos.getSizes.html
[1] http://www.flickr.com/services/api/flickr.people.getPhotos.html
[2] http://www.flickr.com/services/api/misc.urls.html

JT
- --
- ---------------------------------------+--------------------------------
James Tait, BSc | xmpp:jayt...@wyrddreams.org
Programmer and Free Software advocate | Tel: +44 (0)870 490 2407
- ---------------------------------------+--------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/HrpgACgkQyDo4xMNTLiY3OQCg1iUM4YYulx69DJxwYcR8UpH2
k3wAoLX4VO5m+beKvL3/bKrC79aTLdjN
=0W7k
-----END PGP SIGNATURE-----

[Simon Tennant]

The problem is we really don't know what size end applications will want.

Assuming an android app we have a bunch of apps that will probably want to display media (previews) inline and constrain the image to a requested width. 

My vote is to know that this could be a problem in the future and then think about ways to throttle clients IF we see this becoming a problem.

S.

--

Simon Tennant

+49 17 8545 0880

Skype:simontennant

[dodo]

On 31 May 2012 22:30, Simon Tennant <si...@buddycloud.com> wrote:
> The problem is we really don't know what size end applications will want.
>
> Assuming an android app we have a bunch of apps that will probably want to
> display media (previews) inline and constrain the image to a requested
> width.

i think its quiet simple .. we offer a bunch of different sizes and
every time an image is uploaded we resize it.

another way would be to resize on request and then cache the files for
some time.

[Tuomas Koski]

Hi,

On 31 May 2012 23:31, dodo <dodo.t...@googlemail.com> wrote:
> On 31 May 2012 22:30, Simon Tennant <si...@buddycloud.com> wrote:
>> The problem is we really don't know what size end applications will want.
>>
>> Assuming an android app we have a bunch of apps that will probably want to
>> display media (previews) inline and constrain the image to a requested
>> width.
>
> i think its quiet simple .. we offer a bunch of different sizes and
> every time an image is uploaded we resize it.
>
> another way would be to resize on request and then cache the files for
> some time.

Yes.

IMHO In other words: if the platform is able to re-size the image,
awesome! Job done! When the re-sizing is being used and it gets too
"slow / uses too much resources" we can add the cache.

Cheers,
--
Tuomas

[Denis Washington]

Am 31.05.2012 23:31, schrieb dodo:
> On 31 May 2012 22:30, Simon Tennant<si...@buddycloud.com> wrote:
>> The problem is we really don't know what size end applications will want.
>>
>> Assuming an android app we have a bunch of apps that will probably want to
>> display media (previews) inline and constrain the image to a requested
>> width.
>
> i think its quiet simple .. we offer a bunch of different sizes and
> every time an image is uploaded we resize it.
>
> another way would be to resize on request and then cache the files for
> some time.

Actually, I don't see why the server should be able to resize to every
size that the client requests. Clients are not really like 486's
anymore, so I think it's reasonable to offer only a fixed set of sizes
and if the client needs something different, it can just fetch the most
approximate size and do the resizing itself. There is no reason why all
of this work must be loaded off to the server IMO.

Denis

[dodo]

mobile.
resizing on a mobile device hurts a little bit ... but downloading an
image with a decent size is just pure pain.

[Denis Washington]

Today's mobile phones have at least dual-core processors. They also have
OpenGL ES 2.0 GPU's, so you don't actually have to "resize" in that
sense - telling the GPU some texture transformation paramaters is all
that it takes for display.

That being said, I still think there should be multiple pre-computed
sizes. Just not any size.

Denis

[dodo]

resizing is indeed not the problem, but the 300Kbps you get on a mobile device.
sorry for not being clear enough ..

[andy baxter]

Also keeping call charges to a minimum for people on mobile internet
(rather than wifi)

[imaginator]

Thanks for all the feedback. I have updated: https://buddycloud.org/wiki/Buddycloud_HTTP_API#.2Fmedia.2Fname.40example.com.2FmediaID to try and reflect the changes.

Right now we tell developers "use your home domain's API server"  (especially important if there are passwords involved).

However for media queries (.../media/* )  we tell developers "use the remote domain's media server" (especially important if someone for whatever reason was pulling a file like The-Grey-(2012)-DVDRip-XviD-MAXSPEED-BluRAY-5TB-rip from the channel film...@maxspeed.com. And not that bc would ever be used for illegal things).

If everyone is good with this then great. It's slightly confusing to the developer "for one thing talk to this server, for another thing talk to this server".

What can we do to make this experience for the our beloved bc developer less confusing?

S.