Re: What I am missing
On Wed, Nov 19, 2014 at 04:26:48AM +0100, Michaela Merz wrote: > Second: It would be great to finally be able to accept incoming > connections. There's access to cameras and microphones - why not allow > us the ability to code servers in the browser? Maybe in combination with > my suggestion above? Websites would be able to offer webdav simply by > 'mounting' the browser (no pun intended) and the browser would do > caching/forwarding/encrypting .. Imaging being able to directly access > files on a web site without web download. It's not connection oriented, but there is the ability to push opaque junk at the browser via. https://github.com/w3c/push-api You seem to want a more connection oriented stream capability. To satsify, a push-api could have a payload that is a wss:// url it could connect to. Alas push-api is pretty crap- it's just a opaque transfer of whatever. There's no content-type for the incoming push data, no resource identifier, it's just whatever the pusher felt like tossing on the line and no way to do any normal HTTP enveloping. It's utterly mad Push is so opaque. No love on the issue, #81, to spec out some web-like characteristics for it. I have no idea why Push is so ridiculously un-web. :/ https://github.com/w3c/push-api/issues/81 -r
Re: Push API: not a friend of SPDY
Follow-up: there was an issue for meta-data already on the Github. https://github.com/w3c/push-api/issues/81 Please, think of the resources and be webby to one another. Cheerio, rektide On Mon, Oct 27, 2014 at 10:55:40AM -0400, rekt...@voodoowarez.com wrote: > Hello. I heard Push is finally in consideration, and having a link put in > front of me finally got around to > looking- while I'm overjoyed to think the user-agent might expose endpoints, > this implementation is however not > a friend to SPDY (nor a friend to HTTP); comments, 2: > > > SPDY has push. I'd like to see a Push API that can inform the serviceworker > of data pushed via SPDY push. No > endpoint registration is required! It's a capability which already exists in > every SPDY connection, for which > the browser has no corresponding ability to detect the Push. Push already > exists, we just don't signal it. > > Exposing an HTTP server that works as an ingestion endpoint is awesome, it's > far more flexible, and far less > tightly coupled. This absolutely needs to be another, available form of Push > for the user-agent; 100%. > > But I'd also like to be able to use the push channel that already exists. > Please allow SPDY Push to work as a > transport in to Push API. > > > Second, why is no header information available in the Push message? Making > the client a server but then putting > masking tape over the envelope is... un-ethical, brutal, mean, dispirited, > breaks things heniously. People are > going to send HTTP traffic to it anyways, they're just going to have to > wrap/pack unwrap/unpack it, possibly > through someone's reverse proxy. For frell sake, expose the headers. The data > is going to get there, this is > what _is_ going to happen, don't make it a sin of different horrible ways of > munging it together. > > That means you need a little bit more well formed an object for Push message; > one that looks like an HTTP > request. Might I recommend picking the most harmonious, sensible existing > spec out there, such that things > generally work rather than making a brand new IDL for Request? The > dead-obvious no-effort-required > everything-plays-nice developers-don't-laugh-at-you/hate-you-forever options > would be to implement (as closely > as permittable) the existing spec for an http request- > https://fetch.spec.whatwg.org/#request-class > > > I'd point to two previous projects of mine I'd hope Push could help me fully > deprecate & close the book on- > Pipe Layer, a bidirectional asynchronous http over http project, doing an > Opera Unite like thing to reverse > proxy requests received on the server to the browser) > https://github.com/rektide/pipe-layer > Pushchannel, which tracks SPDY Push messages and sends X-Associated-Content > messages in reply to real resource > requests, thereby signalling the user-agent as to the existence of the pushed > resources, > https://github.com/rektide/pushchannel > > Alas, if someone wants to push http traffic to ServiceWorker, they'll ahve to > pack their messages, often times > meaning reverse-proxying through a packing service to achieve interop. WAMP > ho, and that's effing horrible crufty > ugly dumb and unnecessary. > > Alas #2, SPDY's push still doesn't signal and is still all but useless as a > push mechanism. > > > Whether you will this or you wont, still yours, > rektide >
Re: Push API: not a friend of SPDY
On Mon, Oct 27, 2014 at 11:58:03PM -0700, Costin Manolache wrote: > On Mon, Oct 27, 2014 at 11:20 AM, wrote: > > > On Mon, Oct 27, 2014 at 09:28:41AM -0700, Martin Thomson wrote: > > > On 27 October 2014 08:42, wrote: > > > > Anyone who wants to implement a transport can frame it as they please. > > Building > > > > a Push that throws away this information when the message is an HTTP > > message > > > > is something that the lightcone of humanity will hate you for for as > > long as > > > > it holds together. You really really really can not skimp on this > > because you > > > > happen to want other circumstances: if you are building a Push spec > > for the web, > > > > it needs to be able to recieve web-like requsts. > > > > > > > > > That's a pretty strong assertion. Can you provide any justification > > > for that? Any metadata you might want to carry can always be placed > > > in a payload after all. > > > > Not really - the payload is supposed to be end-to-end encrypted, so the > push server can't place anything > in the payload. The push server may want to indicate at least the > (authenticated) source of the > message (unless it operates as an open-relay :-). > > AFAIK http://tools.ietf.org/html/draft-thomson-webpush-http2-00 uses HTTP/2 > for the UA to > push server - which obviously includes the usual headers. So not really > sure what this thread is > about and why the headers would be just dropped in the JS API, I am > assuming they > will show up when a clean way to expose them is found ? This is my concern. I'm concerned that Push API leaves no standard JS API for pushed resources to be seen as resources. Unless Push API has an affordance for exchanging resources, it becomes very very hard to use. For example, a scenario: meatspace, a webapp where a short movie clip and text is sent to everyone looking at a web page. A client would need to get a text message and a video message pushed to it. How does the client know the content-type of the movie clip sent to them? At present, I see no means for the Push API to afford this information, even though it was sent to the WebPush server. Hence my assertion: 1. Headers and method should be optional fields on the Push event (relaying the vital web information- content-type &c) 2. For consistency data should be renamed body. Thank you very much for writing Costin. I greatly appreciate you stating your confusion, and doubly appreciate you asking questions.
Re: Push API: not a friend of SPDY
On Mon, Oct 27, 2014 at 09:28:41AM -0700, Martin Thomson wrote: > On 27 October 2014 08:42, wrote: > > Anyone who wants to implement a transport can frame it as they please. > > Building > > a Push that throws away this information when the message is an HTTP message > > is something that the lightcone of humanity will hate you for for as long as > > it holds together. You really really really can not skimp on this because > > you > > happen to want other circumstances: if you are building a Push spec for the > > web, > > it needs to be able to recieve web-like requsts. > > > That's a pretty strong assertion. Can you provide any justification > for that? Any metadata you might want to carry can always be placed > in a payload after all. I've already discussed packing into the payload: we have specs such as WAMP which we can use to pack CALL/RESPONSE messages to a URL into JSON. We could simply send a valid HTTP response. But how do we get the content-type to know what kind of packing the message has if we start to communicate with an unknown endpoint? This is a spec being built for transfering resources to a user agent. This is undeniable. But the group right now for whatever reason is focused on sending only opaque resources - no content-type, no addressability of the resource being pushed. User agents already receive resources, and when they do those resources are so called because: * They have a URL identifying the resource * They have meta-data describing the conditions of transfer of that resources. You are the WWW consortium: you should be working to send resourceful resources to the user -agent. You shouldn't just cram some new telnet protocol v3.0 (websockets 2.0) into a brand new API in a manner completely decoupled from how the rest of the web works. This work is being done in conjunction with ServiceWorkers, which themselves are 100.000% about resources- yet you are proposing a means of communicating with them which can not talk resourcefully. Why should ServiceWorkers have to fill itself with data passed out of band, via means that Push is itself incapable of equivocating? That seems nonsensical. I would like the working group to move from pushing messages to pushing resources. We are here (the w3) because of resources. This spec should move to push resources. Please respect what is fundamental to the web, and bring Push design more in line with: http://www.w3.org/DesignIssues/Principles.html I'd also point out your charter, which says: "The Web Applications Working Group should adopt, refine and when needed, extend, existing practices where possible." Such as the practice of transmitting resources. Given a couple days of research, I'd also love to point out how using Resources over opaque messages fulfils this line in in your charter- "Furthermore, the Web Applications Working Group deliverables must address issues of accessibility, device independence, internationalization, mobility, privacy, and security." My recommendation is for this spec to define optional (perhaps recommended) "url", and "headers" fields on Push message (domstring/dict), and to rename "data" to "body", establishing a convention for resourceful exchange to happen. If these two steps are done, in addition to fulfilling your charter, I believe the "Provide Channel" step in http://tools.ietf.org/html/draft-thomson-webpush-http2-00#section-2 could be nothing more than a reverse SPDY proxy, which would simplify implementation. As it stands, it's unclear (to me) what exactly the provided channel constitutes. Last an apology; I realize I'm probably not well enough in line with the calm attitude of a working group. Mr Domenic Denicola confirms that in IRC by saying, "i don't really want to get involved in that conversation; the OP's vulgar attitude makes me think engaging will not be constructive." And his words express my own thoughts. I feel enormous passions about this topic, and I have much anxiety about presenting what to me is an obvious, clear, simple fix with a direct clear and obvious mandate, one which will Move The Web Forward, which pushes us towards The Web We Want, which arrives us at a resourceful/web future, and I see such a massive colossal distance that I feel I will never come anywhere near close to cracking, a distance I cannot fathom; and this, at least, what I come as, is honest and not overly plucked. But I am sorry for tracking personal noise into this channel, and I am sorry for the additional burden I levy by not having the experience, confidence or connections to better massage my mess of feelings into a manner more appropriate for this working group's direct consumption. Thank you for attending. I've To:'d two people who I'd appeal to for help maintaining a web built of resources, although I'm far from sure they'll agree with the connection I'm trying to suggest between Push and opaque/web messaging/resouces. regards, yours, rektide
Re: Push API: not a friend of SPDY
> Keeping a connection established, even using long polling, can increase > battery usage, network noise and decrease reliability. Allowing the user > agent to curate such messaging through a single connection, for example an > operating system provided push service, removes the need for additional > connections and/or background processes for each website insisting on using > their own service. This is especially important on mobile devices. I'd love for you to tell me how QUIC fails to supply this. > The Push API itself does not dictate a transportation mechanism. Then you MUST mandate the transport mechanism include basic web semantics- verb, url, headers, body. Anyone who wants to implement a transport can frame it as they please. Building a Push that throws away this information when the message is an HTTP message is something that the lightcone of humanity will hate you for for as long as it holds together. You really really really can not skimp on this because you happen to want other circumstances: if you are building a Push spec for the web, it needs to be able to recieve web-like requsts.
Re: Push API: not a friend of SPDY
On Mon, Oct 27, 2014 at 03:12:05PM +, Peter Beverloo wrote: > On Mon, Oct 27, 2014 at 2:55 PM, wrote: > > > Hello. I heard Push is finally in consideration, and having a link put in > > front of me finally got around to > > looking- while I'm overjoyed to think the user-agent might expose > > endpoints, this implementation is however not > > a friend to SPDY (nor a friend to HTTP); comments, 2: > > > > > > SPDY has push. I'd like to see a Push API that can inform the > > serviceworker of data pushed via SPDY push. No > > endpoint registration is required! It's a capability which already exists > > in every SPDY connection, for which > > the browser has no corresponding ability to detect the Push. Push already > > exists, we just don't signal it. > > > > Exposing an HTTP server that works as an ingestion endpoint is awesome, > > it's far more flexible, and far less > > tightly coupled. This absolutely needs to be another, available form of > > Push for the user-agent; 100%. > > > > But I'd also like to be able to use the push channel that already exists. > > Please allow SPDY Push to work as a > > transport in to Push API. > > > > It sounds like you're searching for something like > http://dev.w3.org/html5/eventsource/, but with event delivery to a Service > Worker. > > Keeping a connection established, even using long polling, can increase > battery usage, network noise and decrease reliability. Allowing the user > agent to curate such messaging through a single connection, for example an > operating system provided push service, removes the need for additional > connections and/or background processes for each website insisting on using > their own service. This is especially important on mobile devices. > > The Push API itself does not dictate a transportation mechanism. EventSource is close, except it too (like Push) is a higher level protocol on top of HTTP. In this modern new awesome world with great tech, we can actually just Push without having to build a higher level protocol- all we need is for the browser to be signalled for what has already happened. So, like EventSource, except entirely free and requiring no new protocols or systems of exchange what-so-ever and being totally baked in already. EventSource is also not web. It's just a stupid text resource. I'd like to expose the actual Push mechanism actually underlying the web everyone is already using. > Second, why is no header information available in the Push message? Making > > the client a server but then putting > > masking tape over the envelope is... un-ethical, brutal, mean, dispirited, > > breaks things heniously. People are > > going to send HTTP traffic to it anyways, they're just going to have to > > wrap/pack unwrap/unpack it, possibly > > through someone's reverse proxy. For frell sake, expose the headers. The > > data is going to get there, this is > > what _is_ going to happen, don't make it a sin of different horrible ways > > of munging it together. > > > > User agents are free to choose their own message transportation mechanism. > As a developer, you send a message to the push service (e.g. Google Cloud > Messaging) rather than to the user, which then forwards it accordingly. > Many of such services dictate a certain message format or header format. > > There is an ongoing effort to standardize a server-to-server protocol to > enable delivery of more inclusive messages. I encourage you to participate > if this yields your interest. (It is based on HTTP/2.) > http://datatracker.ietf.org/wg/webpush/documents/ This looks exactly like my Pushchannel project. Which I want to deprecate and not implement, because SPDY and QUIC have Push and all we need is an API for generic notification of asserted resources. Aka Push. It's absurd that we'd build a spec for Push based exclusively around _old_ ancient paths for HTTP that willfully ignores the actual underlying transport's capabilities to actually push.
Push API: not a friend of SPDY
Hello. I heard Push is finally in consideration, and having a link put in front of me finally got around to looking- while I'm overjoyed to think the user-agent might expose endpoints, this implementation is however not a friend to SPDY (nor a friend to HTTP); comments, 2: SPDY has push. I'd like to see a Push API that can inform the serviceworker of data pushed via SPDY push. No endpoint registration is required! It's a capability which already exists in every SPDY connection, for which the browser has no corresponding ability to detect the Push. Push already exists, we just don't signal it. Exposing an HTTP server that works as an ingestion endpoint is awesome, it's far more flexible, and far less tightly coupled. This absolutely needs to be another, available form of Push for the user-agent; 100%. But I'd also like to be able to use the push channel that already exists. Please allow SPDY Push to work as a transport in to Push API. Second, why is no header information available in the Push message? Making the client a server but then putting masking tape over the envelope is... un-ethical, brutal, mean, dispirited, breaks things heniously. People are going to send HTTP traffic to it anyways, they're just going to have to wrap/pack unwrap/unpack it, possibly through someone's reverse proxy. For frell sake, expose the headers. The data is going to get there, this is what _is_ going to happen, don't make it a sin of different horrible ways of munging it together. That means you need a little bit more well formed an object for Push message; one that looks like an HTTP request. Might I recommend picking the most harmonious, sensible existing spec out there, such that things generally work rather than making a brand new IDL for Request? The dead-obvious no-effort-required everything-plays-nice developers-don't-laugh-at-you/hate-you-forever options would be to implement (as closely as permittable) the existing spec for an http request- https://fetch.spec.whatwg.org/#request-class I'd point to two previous projects of mine I'd hope Push could help me fully deprecate & close the book on- Pipe Layer, a bidirectional asynchronous http over http project, doing an Opera Unite like thing to reverse proxy requests received on the server to the browser) https://github.com/rektide/pipe-layer Pushchannel, which tracks SPDY Push messages and sends X-Associated-Content messages in reply to real resource requests, thereby signalling the user-agent as to the existence of the pushed resources, https://github.com/rektide/pushchannel Alas, if someone wants to push http traffic to ServiceWorker, they'll ahve to pack their messages, often times meaning reverse-proxying through a packing service to achieve interop. WAMP ho, and that's effing horrible crufty ugly dumb and unnecessary. Alas #2, SPDY's push still doesn't signal and is still all but useless as a push mechanism. Whether you will this or you wont, still yours, rektide
Re: IndexedDB, what were the issues? Non-reactable.
Part 1 - Finding issues, preventing recurence This thread started as counter-rabble rousing. This search for problems, wanting desperately to find some, to hunt for paths for avoiding a recurence- has yielded IMO triflingly small big results. Alex's discussion about understanding the state machine, about it not being exposed yet having rules it expects, rings true with my own small experience with IndexedDB spec reading I've done. In contrast my experience engineering IndexedDB powered play-toys constrasts strongly: the spec just works without complication for my kind of very basic use cases. And I don't see a whole lot having reviewed the core point, which wasn't this spec, but how we avoid repeating the "mistakes." Having not found much consititueable as a mistakes this is IMO a hard case to learn from- but I think that original question was a cultural one, and I'd call out that question as having gotten burried, which is natural along-side my claim that there ain't much in the way of real actual problems around here. Part 2 - An issue I do have one issue I'd raise- I'd love a more reactive data-store. When something changes it's more often the edge- the change- that is interesting than the state or the value. We've recently added what IMO is the most important advancement in the web, Observers, and damnit I demand my data-store be observable too: places to dump bits ought be on the line to report what bits are being dumped into them. Developers require all systems be able to report what's happening, without requirying the entire data set comparing versus some separate cache. This is, imo, the capital lacking area IndexedDB has failed to touch upon. I'd prefer an IndexedDB that at a minimum allows multiple active pariticpants (those holding the data-store open at the time) to see what changes are being made to the store. I'd further enjoy & relish in an IndexedDB that allowed me to setup persistent event sources that when reconnected to would report on the changes they had been set up to monitor and log. This is indeed implementable with a wrapper on top (& so was scanning the DOM for changes, but many reactive systems resorted to .get/.set wrappers alike this wrapper). I'd like to see some natural reactivity in the spec, some way for the IndexedDB to itself report what is going on inside the store beyond the scope of schema changes, rather than this being a supplemental grafted on system to the data-store. In Cassandra world, to pick one random data-store example also discussing this broad topic there's CASSANDRA-1311 - Triggers, to allow the Cassandra database to signal changes to the store and perhaps perform actions in response. I think this is an important topic that IMO has been largely overlooked, and I'd love to see a reactive data store that could be more readily used in MVC use cases to act as a system of record to populate and keep in sync dependent systems. https://issues.apache.org/jira/browse/CASSANDRA-1311 Part 3 - Thanks Thanks for reading. I'm so happy to have a data-store in the browser, and I think the spec as it stands does well what it set out to do, and I look forwards to second passes to make it look aesthetically kinder. Godspeed all. Fair regards, m rektide de la faye fowle
Re: Trialing Web Components
I did! Pardon, thanks for the fixed URL. https://gist.github.com/3078197 On Mon, Jul 09, 2012 at 03:21:50PM -0400, Scott González wrote: >On Mon, Jul 9, 2012 at 3:09 PM, rektide <[1]rekt...@voodoowarez.com> >wrote: > > My attempt is at: > [2]https://gist.github.com/3078187 > >I think you meant [3]https://gist.github.com/3078197
Trialing Web Components
Hi,
What options are there for trying Web Components work?
I'm trying to follow the models set out in what is in
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html but I
haven't gotten
anything working thus-far: my and tags appear to be
silently ignored,
and their known html content executed.
My attempt is at:
https://gist.github.com/3078187
Chrome Canary reports:
22.0.1201.0 (Official Build 145644) canary
"C:\Users\rektide\AppData\Local\Google\Chrome SxS\Application\chrome.exe"
--flag-switches-begin --enable-accelerated-video-decode --enable-css-regions
--enable-devtools-experiments --enable-extension-activity-ui
--enable-peer-connection
--enable-shadow-dom --enable-style-scoped --flag-switches-end
Last, a question; is there any way from the 'create' or 'insert' lifecycle
event to read the
attributes one has set on one's instance? I was rather expecting the Shadow
Root, although,
yes, is a DocumentFragment, not something that typically exposes attributes,
ought have some
stateful means I could use to ask.
Regardling this last problem, I did notice the following line, and haven't seen
any
documentation or description of what it is or where it comes from, and it
appears to be in
the domain, although my naive reading would make me think it is an edge
triggered callback
rather than a queriable level inherent to the Shadow document:
this.reflectAttribute('list', 'list', Helper.prototype._settingsChanged);
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/samples/entry-helper.html
Thanks. If there's some way to fiddle with Web Components, would like to be
doing so. Good
day.
