Re: Updated understanding by Ian [Was: Project status]

On 12/4/12 8:22 PM, "Ian Jacobs" <ij@w3.org> wrote:

>Hi Tobie,
>
>Thank you for the chat today. Here is my updated understanding:
>
>* The scope of the project you have in mind is a Web app to:
>
>   - take and store photos locally
>   - view those photos, individually and in a "gallery"
>   - manipulate the photos in a few ways (e.g., apply filters).
>   - share the photos. Here "share" means "push to some service with no
>ability to undo that action, and no
>     sync functionality." I presume that different parties could share to
>the same external service. There
>     will be several sharing services available, and people will choose
>the one they want in the UI.
>* You are planning to create a simple API for sharing, and to support
>sharing to Facebook and Dropbox.
>   Letting users view or otherwise manipulate the shared photos is the
>purview of the service. Thus, the
>   camera app itself will not provide a "shared gallery view" but rather,
>if you've shared to dropbox, people
>   can use Dropbox to view the photos.

That's correct.

>Here are additional notes specific to our MWC demo:
>
>* We will want to display the shared gallery on screens of different
>sizes (e.g., mounted on a wall).
>
>* Those machines will all have browsers.
>
>* One solution for showing the shared gallery is to point the device's
>browser at Dropbox's Web site,
>  which has a photo gallery functionality. This has the benefit of
>requiring no effort, as long as the browsers
>  in questions support the HTML/CSS/JS used by dropbox. However, if
>someone shares a new photo
>  and we want the browser's view updated automatically, we currently do
>not think dropbox will do that.

This is correct too.

> * Another solution would be an HTTP POST solution. In the general HTTP
>POST scenario, you need to
>   address any cross-origin questions and be authorized to post to a
>given URI. You mentioned using
>   server-sent events as a means to tell the app "a new photo has
>arrived" and that the app displays the
>   new image.

Very confused about this part here. Also calling this an HTTP POST is a
misnomer as all solutions that involve posting an image to a server imply
HTTP POST requests.

> * Furthermore, you made the point that the cross-origin issue goes away
>if the same server is used both
>   to store the photos and to host the gallery app.

That's incorrect actually. SOP is mostly a problem to POST images, not so
much to GET them. Also if the server doesn't have any data you're worried
about being accessible, it can be CORS-enabled, and SOP is no longer
relevant.

>We can set that up. Here is a setup we had in mind:
>       - We have a laptop that is running an http server (that receives
>photos and serves the gallery app).

It needs to also serve the camera app or to be CORS enabled.

>       - The other devices (phone, tablet, TV) connect to the laptop
>through wires (e.g., through a switch or
>         hub). We don't even need Internet access to run the demo. (If we
>have internet access, e.g., wired,
>         we can consider the Dropbox option as well).

Sounds good.

>       - The phone shares to the server through either wifi or bluetooth.
>(There are not-too-expensive
>         bluetooth routers available...we think with sufficient bandwidth
>but have not tested.)

I do not have any experience running HTTP traffic over Bluetooth. A quick
Google search seems to imply tat's it's possible but non-trivial. It might
restrict the kind of device we can use for the camera app which might be
an issue.

>  * You mentioned being able to write the plugin that saves images to the
>laptop;

I mentioned that I am happy to write the JS code that posts the image to
an end point and does the authentication, provided the server has an API
to do both (if this is running on a closed network, auth might not even be
necessary).

However, the server side component that's going to process and store the
images and do the authentication is not something I have the time to work
on.

>that would be great (if
>    we choose this route rather than dropbox or some other service).
>(During our discussion you mentioned
>     needing an authorization callback [which for same-origin might
>return true all the time] and
>     a function to post photos to the server using XHR.)

Yes, that was an example API for sharing. We'll see what we end up with
once we code the Dropbox and FB examples.

>  * That leaves writing the app that displays photos (e.g., using
>different layouts depending on screen
>    dimensions) and where the view is updated when new photos are shared.

Yes, that and the server side component that serves the apps and stores
the pictures.

In summary:

We agree that there are four components to this project:

1) The camera app, as described before, which is what Nokia and myself are
working on.
2) A gallery application, which is what Joshfire will be working on.
3) A server side component, which is going to store the pictures, serve
them and possibly serve both apps. This is going to be built by W3C.
4) A bit of JavaScript code which is going to be the interface between the
Camera app and the server-side component. This I will write once the
server side component has been developed.

Best,

--tobie

Received on Tuesday, 4 December 2012 21:23:22 UTC