| 10:11 | <Ms2ger> | annevk, you don't happen to be around? |
| 10:12 | <Ms2ger> | Oh, nvm |
| 10:20 | <annevk> | Ms2ger: waddup? |
| 10:30 | <Ms2ger> | annevk, I thought a note in the encoding spec was wrong, but I misdiagnosed the error |
| 10:30 | <annevk> | ah |
| 10:31 | <Ms2ger> | Though I'm still not entirely sure it isn't wrong |
| 10:31 | <Ms2ger> | https://encoding.spec.whatwg.org/#dom-textencoder-encode |
| 10:31 | <Ms2ger> | Claims "These encodings cannot return error.", but I don't see why not |
| 10:32 | <Ms2ger> | Oh, USVString |
| 17:09 | <rektide> | in BroadcastChannel, there's no means available for discoverability |
| 17:10 | <rektide> | as a service provider, i'd like to be able to advertise my channel to other channel-users |
| 17:10 | <rektide> | they have to know ahead of time all the channels they might ever want to use |
| 17:11 | <rektide> | and that seems markedly anti-web, anti loose coupling |
| 17:11 | <rektide> | i made a similar bid for freedom in BroadcastChannel's unicast brother, navigator.connect |
| 17:11 | <rektide> | https://github.com/mkruisselbrink/navigator-connect/issues/1 |
| 17:11 | <rektide> | and got ignored there too as i always do by you very smart people |
| 19:19 | <Hixie> | rektide: just define a channel to advertise on |
| 19:19 | <Hixie> | rektide: and then advertise on there |
| 19:19 | <Hixie> | rektide: (since broadcast channels are per-origin, though, you can just tell your fellow web masters about them) |
| 19:20 | <rektide> | defining a well known advertisement channel doesn't seem different from making people join your well known actual channel. |
| 19:21 | <rektide> | you end up needing intermediating hubs where people can agree to advertise to one another |
| 19:21 | <rektide> | i'd much prefer a web that is able to form itself |
| 19:21 | <rektide> | #webwewant2015 |
| 19:21 | rektide | chagrins himself |
| 19:24 | <rektide> | Hixie: Marijn comes up with the same argument against discoverability in https://github.com/mkruisselbrink/navigator-connect/issues/1#issuecomment-62989902 and has a prototype example in his navigator.connect world |
| 19:26 | <rektide> | i don't see why my user agent would not permit pages that wish to register the services they have to present that to the browser |
| 19:27 | <Hixie> | i'm not arguing against discoverability |
| 19:27 | <Hixie> | i'm arguing that it's already possible |
| 19:27 | <Hixie> | in any case, it's not like you can easily use randomly discovered channels, i mean, they're each going to have their own semantics and protocols |
| 19:28 | <rektide> | that is so irrelevant |
| 19:28 | <Hixie> | seems most relevant to me :-) |
| 19:28 | <rektide> | send messages to the channel. if it replies in a way you can accept, you can de facto converse |
| 19:28 | <rektide> | there's no need to assume anything at all beyond that ever |
| 19:28 | <rektide> | you are for your local pair sure of completeness |
| 19:30 | <rektide> | any discussion on the need for content-negotiation is a forced one. please don't distract by insisting there's relevance to content negotiation |
| 19:32 | <rektide> | there's a basic capability: can a page tell the user agent that it wishes to be able to be found |
| 19:33 | <rektide> | defining an answer such that "sure, you can find the page if you know that there's this one url that you can hit" |
| 19:33 | <rektide> | my answer is that no, the User-agent is not really bestowing the capability in earnest to the page |
| 19:34 | <rektide> | we're getting awesome listenability mechanisms from navigator.connect and broadcast channel but neither of them are things where the user-agent is doing the job it needs to do to help things that want to be discoverable and which want to converse |
| 19:34 | <rektide> | to be talk-to-able |
| 19:42 | <Hixie> | i've no idea what "can a page tell the user agent that it wishes to be able to be found" means but it doesn't sound like broadcast channels attempt to go near that problem? |
| 19:42 | <Hixie> | i guess i don't understand your high level problem |
| 19:42 | <Hixie> | are you asking about the equivalent of android intents? |
| 19:44 | <rektide> | the most appropriate thing i could cite would be the Network Discovery spec |
| 19:44 | <rektide> | i would like for BroadcastChannel to be something that the owner can set a flag on- myBroadcastChannel.makeDiscoverable() |
| 19:45 | <rektide> | and from another origin or page i can do a BroadcastChannel.findAllDiscoverable() or some such |
| 19:46 | <Hixie> | let's go higher-level. what's the user-facing problem you're trying to solve? |
| 19:46 | <rektide> | it may perhaps be useful if one were trying to implement something like Android Intents |
| 19:47 | <rektide> | if i'm twitter, i'd like for every page on the system to be able to know the feed of the user |
| 19:47 | <rektide> | if i'm stock ticker website, i'd like for every page on the system to be able to see live stock ticks |
| 19:47 | <rektide> | if i'm a weather site, i'd like for every page on the system to be able to see the weather reports the user looks for |
| 19:48 | <rektide> | as those sides, i want to broadcast a stream of json-ld data |
| 19:48 | <rektide> | *sites |
| 19:48 | <Hixie> | oh, well |
| 19:48 | <Hixie> | you can do that already |
| 19:48 | <rektide> | if they know i'm there broadcasting |
| 19:48 | <rektide> | hence: discoverability |
| 19:49 | <rektide> | othrewise you fail the basic condition |
| 19:49 | <rektide> | i want every page to be able to see |
| 19:49 | <rektide> | unless your ego is so large you assume everyone already knows you are there |
| 19:49 | <Hixie> | so you're saying the user-facing problem is you want the user to open two tabs, that don't know about each other, and for the data from one tab to go to the other tab? |
| 19:50 | <rektide> | yes |
| 19:50 | <Hixie> | why the heck wouldn't the user just go to the twitter tab to see the twitter feed?? |
| 19:50 | <rektide> | (please please please don't me eat this ack) |
| 19:50 | <rektide> | i dunno, that's not my use case? |
| 19:50 | <rektide> | why would they have to? |
| 19:50 | <Hixie> | i don't understand your use case at all |
| 19:50 | <rektide> | why is the twitter background page color blue? |
| 19:51 | <Hixie> | if i want to view my twitter feed, i don't open g+ and hope that g+ notices i have twitter open to display my twitter feed there. |
| 19:51 | <Hixie> | especially since twitter is going to be able to do a much better job of rendering it |
| 19:51 | <rektide> | in livejournal, when you are authoring a post, there is a "now listening" button that could detect the music from a few known sources |
| 19:51 | <Hixie> | ah now that's a more concrete use case |
| 19:51 | <rektide> | i just want to make my own personal audioscrobbling server- which i wrote then literally lost the source to- |
| 19:52 | <rektide> | well i've given you something consumer-side this time |
| 19:52 | <Hixie> | yes, that's what i meant by "user-facing" |
| 19:52 | <rektide> | google now would be an example of a user-facing consumer of feeds |
| 19:52 | <Hixie> | ok so today the only way to do that that i can imagine is that you have an intermediary site that is a well-known place for producers and consumers to go to |
| 19:52 | <rektide> | yes me too and marijn too |
| 19:53 | <Hixie> | they each open an iframe to that site, that iframe opens a shared worker, and everyone talks back and forth over that channel |
| 19:53 | <Hixie> | if you want that to happen but with the browser being the intermediary rather than some random well-known third-party site, then you probably want anne's hypothetical web intents stuff |
| 19:54 | <Hixie> | i recommend sending anne feedback on that |
| 19:54 | <Hixie> | giving that use case, in particular |
| 19:55 | <rektide> | i am loath to let such a specific user-facingness use-case copt the more general idea of discoverability |
| 19:55 | <rektide> | but that doesn't roll back- |
| 19:55 | <Hixie> | if you want something more general, describe more use cases so that it's obvious why you need something general |
| 19:55 | <rektide> | Hixie: thank you for discussing with me this |
| 19:56 | <rektide> | Google Now is a beautiful omnibus consumer of all the datas |
| 19:56 | <rektide> | pointing to it and saying "web" is really kind of all the stand i feel like i should have to make |
| 19:57 | <rektide> | omnivore post-application user-augmentation ware |
| 19:58 | <rektide> | but it'll be fun rattling my brain to dredge up some existing application's that peer to other local wares |
| 19:59 | <rektide> | once more chagrined, i just want to say thanks again for taking the time and inquiry to get us togther to the destination i saw |
| 20:00 | <Hixie> | the way to get things on the web is to describe the end-user use case. which in any case is what should matter, right, i mean who cares HOW something ends up being possible as long as it's possible |
| 20:02 | <rektide> | it's something not modelled much in the world about, but inside of me i know that the agencies i wish to seed are ones which exchange with others and which can be heard from. and i believe we've come to a concensus on what the state of affairs is for that possibility. |
| 20:02 | <rektide> | dbus is the most successful example by far, and it's success is meager. there are some very cool adoptions- MPRIS media playing remote interface specification- is really powerful and really well used |
| 20:03 | <rektide> | but overall adoption is in a directly bad state, even where this capability of being talk-to-able exists, is very low |
| 20:05 | <Hixie> | in my experience, trying to provide hooks for hypothetical general solutions works far less well than trying to solve actual concrete problems that have immediate needs. |
| 20:06 | <rektide> | but then you are married to your limited concrete set of the problem |
| 20:06 | <rektide> | that's a negligent and dangerous path |
| 20:07 | <rektide> | it also means you have to lead with problems, rather than hunting opportunity |
| 20:07 | <rektide> | talk about a convergent path to local maxima |
| 20:08 | <rektide> | but as far as getting others onboard, i certainly see what you are saying being the patterened way to get stuff done |
| 20:09 | <Hixie> | i agree that in theory it sounds like you'd get better results long term if you provided general solutions to hypothetical general problem spaces instead of generalised solutions to targetted problems |
| 20:09 | <Hixie> | but in practice it never works |
| 20:09 | <Hixie> | the specific has a way to focus the solution to one that actually works |
| 20:09 | <Hixie> | whereas general solutions tend to become quagmired in theoretical problems |
| 20:09 | <rektide> | well thankfully i'm not providing a general solution, i'm just trying to solve a specific problem- i want people to know the software i write exists |
| 20:09 | <Hixie> | google already solves the problem of "i want people to know the software i write exsits" |
| 20:10 | <rektide> | well said |
| 20:10 | <rektide> | ahhhh lol |
| 20:10 | <Hixie> | so clearly that's not exactly the problem you're trying to solve :-) |
| 20:10 | <Hixie> | the web, for example, was a concrete solution to a narrow problem: how to share data at CERN. yet it worked out that it was a great base for a more general problem. compare to the other solutions to the more general problem that have been proposed, but have gone precisely nowhere. |
| 20:11 | <Hixie> | (in fact that most people have never heard of) |
| 20:11 | <rektide> | i guess i have a hard time seeing what you would do to my solution statement- |
| 20:11 | <Hixie> | SGML vs XML is another example. SGML tries to solve more problems than SGML. |
| 20:12 | <Hixie> | than XML, i mean |
| 20:12 | <Hixie> | yet XML is way more successful |
| 20:12 | <rektide> | myBroadcastChannel.makeDiscoverable() / BroacastChannel.findAllDiscoverable()- is that in the bad/general side to you? |
| 20:13 | <rektide> | that fails for not having a well targetted problem, for being general to you? |
| 20:14 | <rektide> | i feel like assuming more factors, having a more built out problem set-up- like yes perhaps the web intents works- would just be a receipe for making more ancillary downstream problems by baking in yet more assumptions |
| 20:14 | <rektide> | http://www.w3.org/TR/discovery-api/ is an example of what i feel is a near ideal extensible api, which makes few assumptions. acctually, i think it'd be a great consumer for a myBroadcastChannel.makeDiscoverable()! |
| 20:15 | <Hixie> | broadcast channels are per-origin so they don't solve this at all |
| 20:16 | <Hixie> | http://www.w3.org/TR/discovery-api/ makes no sense to me |
| 20:16 | <Hixie> | but ok |
| 20:16 | <rektide> | oh. heh, well. |
| 20:16 | <Hixie> | bbiab |
| 20:16 | <rektide> | i rescind any asks of #whatwg now seeing that broadcastchannel doesn't have cross origin capabilities. |
| 20:39 | <rektide> | i did a pretty crude port of Marijn's discovery-via-intermediary to broadcast channel, but obviously it's frivolous work when there's no cross-origin scenario to do it across. https://gist.github.com/rektide/36c5ec5301fb17f37ea6 |
| 22:28 | <zewt> | ebay doesn't allow pasting in passwords; it's nonsensical that browsers even allow pages to affect that |
| 23:26 | <smaug____> | zewt: well, web pages can just reimplement type="password" themselves |