W3C home > Mailing lists > Public > public-coremob-camera@w3.org > December 2012

Updated understanding by Ian [Was: Project status]

From: Ian Jacobs <ij@w3.org>
Date: Tue, 4 Dec 2012 13:22:18 -0600
Cc: "public-coremob-camera@w3.org" <public-coremob-camera@w3.org>
Message-Id: <E54D824E-495A-436C-8398-699774267919@w3.org>
To: Tobie Langel <tobie@fb.com>
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.

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.

 * 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. 

 * 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. 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).
       - 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).
       - 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.) 

  * You mentioned being able to write the plugin that saves images to the laptop; 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.)

  * 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.

Did I get it?

Ian
--
Ian Jacobs (ij@w3.org)    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447
Received on Tuesday, 4 December 2012 19:22:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 December 2012 19:22:22 GMT