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

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

From: Ian Jacobs <ij@w3.org>
Date: Tue, 4 Dec 2012 17:20:15 -0600
Cc: "public-coremob-camera@w3.org" <public-coremob-camera@w3.org>
Message-Id: <92D7C6B9-E054-47DC-8489-6EC9E48AC4D4@w3.org>
To: Tobie Langel <tobie@fb.com>

On 4 Dec 2012, at 3:22 PM, Tobie Langel wrote:

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

[snipping stuff that's true ;) ]

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

Right, HTTP POST is under the hood. I was talking about using js primitives to do
xhr or whatever rather than higher level APIs to interact with some service.

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

Right; I was only talking about the POST here.

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

Agreed.

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

Yes. Sorry I meant to say that, too.

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

Ok. We'll need to explore further. 

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

Ok.

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

Understood.

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

I think Joshfire was to focus on the TV part, but if we can expand that to "gallery app
for displaying shared photos on tv, tablet, or phone" yes, that would be great.


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

Yep.


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

What do you need to connect? (e.g., a URI for post. anything else?)

Ian

> 
> Best,
> 
> --tobie
> 
> 

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

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