This seems like a safe-api issue in that wasm isn’t/wasn’t detected at upload (or isn’t supported atm). I’ll make an issue to check into that.
You’re getting a return, much like the
cat command, which is also using fetch, so you can access the raw data in the
data field of your
PublishedImmutableData. That should be get you going as things stand.
We havent actively crippled that functionality, so such things should be available… Though I’m not familiar with what they do under the hood so can’t say for sure that they will work. The browser is built on electron, which is chromium. So it should support all things as chrome does, aside from the notable aspect of blocking http requests (for security).
That said, looking at the name, I’d assume
streaming won’t necessarily work at the mo if that’s needing HTTP headers, for data ranges… I’m not sure.
This is kind of the bigger topic we touch on above. Should our API simulate a HTTP request to this end? (In rust or browser or wherever). And if so, why?
It’s not so much that we don’t expect much use of fetch, these APIs are new, non finalized, and yeh, there’s this bigger Q of backwards compatability and if/where that should live in the stack…
Compatibilty with Yew/fetch in general may be a nice thing to have, sure. But from an functionality standpoint, running a server that maps requests to SAFE would enable yew to work against that server (from what i understand, if we’re just fetching things from servers here), that doesnt sound like core api functionality.
That something doesn’t work off the bat, isn’t a reason to force compatibility with an old protocol, potentially increasing the security surface and the like.
Yew there is working with HTTP requests, so yes, that’s not compatible. But depending on what Yew actually needs in terms of data, the ideal (IMO) would be for Yew itself to support
safe: urls, and not need to go through any HTTP spoofing.
What do we need for that? Well, a good API really. So it comes down to a question of what’s missing. And then we get that in.
Right now you’re blazing a bit of a trail (i don’t think even @happybeing has diven into these APIs yet), so there’s almost certainly going to be improvements wanted.
To be clear though: none of this isn’t to say that we don’t need a fetch api, in some form. Again, a wrapper around the browser may be useful in the short term, or a wee server for pinging requests onto safe may be useful. But should those be core API functionalities? (And what sort of priority should we give them?)
At the moment, I think you can use
safe.fetch as you are. And grab the
data portion of your
PublishedImmutableData, this should be a
string of the data (or perhaps just the raw bytes if the type is unknown right now; not sure off the top of my head).
From your code above, this is what (i think you need for feeding in to the