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, rekt...@voodoowarez.com wrote: On Mon, Oct 27, 2014 at 09:28:41AM -0700, Martin Thomson wrote: On 27 October 2014 08:42, rekt...@voodoowarez.com 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.
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: 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 09:28:41AM -0700, Martin Thomson wrote: On 27 October 2014 08:42, rekt...@voodoowarez.com 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: 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
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 element and template 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.
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
