new WAPI+WUI proposal

[Lukas Pirl]

Hi Brian,

I am currently using Tahoe as a demo "business application" for fault
injection experiments targeting an IaaS platform.

To be frank, it is annoying that apparently HTML has to be parsed to
get all the nice performance counters Tahoe provides (for evaluation,
solely the WEB API can be/should be/is consulted in my case and most
pages are not available as JSON).

Hence, I want to stress my point once again, that it would be most
awesome to have a clear separation between the WEB API and the WUI. It
would enforce a rich API in a sustainable manner. And of course the
separate content delivery.

$ 0.02

Cheers,

Lukas

On 07/02/2016 11:11 PM, Brian Warner wrote as excerpted:
> On 7/1/16 6:41 AM, Lukas Pirl wrote:
> 
>> It is surely a matter of taste and semantics but one could argue that
>> it's a bit funny that a Web API delivers fancy JS-based HTML pages.
> 
> Good point!
> 
>> * WAPI (HTTP/CBOR only): note control, directory browsing
>> * WUI (HTML/JS): HTML user interface to WAPI
>> * WCD (Web content delivery? However you call it):
>>   delivery of grid-stored files
> 
> Yeah. I think I'd want to enable CORS on the WAPI port (telling browsers
> that it's ok for pages from any origin to make WAPI requests), and
> design the WAPI to make that safe (e.g. *everything* requires a cap of
> some sort, zero ambient authority). But if we *didn't* do that, there
> might be an argument to put both WAPI and WUI on the same port, giving
> the WUI pages permission to access the WAPI, but no other
> browser-delivered pages.
> 
>> That way, the WUI could be handled as separate "app", connecting to
>> the WAPI like everything else. Maybe there are even scenarios where
>> you want to distribute those services over multiple machines?
> 
> Possibly, yeah. You could configure a remote Tahoe client/gateway (say,
> on a VPS machine) to have the WAPI listen port on HTTPS and an external
> interface (instead of defaulting to 127.0.0.1 and unencrypted HTTP).
> Then maybe use a command like "tahoe webopen --token XYZ --wapi
> wss://tahoe.my-vps.example.com:3457/v1", which would use a local copy of
> the WUI (served from 127.0.0.1:3458) but tell it to talk to the remote
> WAPI port, and take an explicit token instead of reading it from the
> local basedir.
> 
> I need to look into how IPFS does this. I know their WUI equivalent is
> stored in IPFS too, but I think they have two separate ports, and I
> think they rely on same-origin protection for safety against malicious
> documents.
> 
> cheers,
>  -Brian
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
> 

-- 
+49 174 940 74 71
GPG: http://lukas-pirl.de/media/attachments/lukas_pirl.pub