Re: [whatwg] Some likeness of DOM Session scope
Ian Hickson wrote: I looked at this but could not immediately work out how to leverage this idea in the context of HTML5, unfortunately. Do you know if any work is being done on POEs still? I'd be surprised if Mark (the author) didn't want to move forward with it. There are some related problems in the Atom Publishing Protocol, and POE is one solution being considered. If you have feedback, or changes that would make it more usable with HTML5, it's worth contacting him. Robert Sayre
Re: [whatwg] Some likeness of DOM Session scope
On Thu, 21 Apr 2005, Kornel Lesinski wrote: On Thu, 21 Apr 2005 14:07:45 +0100, Ian Hickson [EMAIL PROTECTED] wrote: Anyone have any concrete proposals? :-) Persistent associative array that stores anything*, just like session object in PHP and ASP. This might be called: document.localCookies Is window.sessionStorage and window.globalStorage ok? Scope would be just like in HTTP cookies, but these wouldn't be sent to the server and wouldn't have length limit. To store object: document.localCookies['key_name'].value = anything; To retrieve object: anything = document.localCookies['key_name'].value; Yup, pretty much exactly that: To store object: window.sessionStorage['key_name'].value = anything; To retrieve object: anything = window.sessionStorage['key_name'].value; * only /Storable/ objects should be allowed. Storable objects are the ones that implement sleep and wake methods that (un)serialize them. That would be save/load XML for DOMNodes, toString/parseInt/etc for basic types. Not quite the way I defined it, but the idea is the same. Thanks for the feedback, please let me know if the proposal is ok: http://whatwg.org/specs/web-apps/current-work/#client-side -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some likeness of DOM Session scope
On Thu, 21 Apr 2005, Olav Junker Kjær wrote: Anyone have any concrete proposals? :-) How about a javascript structure which may be arbitrary deep, but only may contain javascript built-in types (Object, Array, string, number, bool, Date etc.)? This would be very easy to use, although it might be confusing for authors that you can save a string but not e.g. a textnode. That's vaguely what I ended up doing, though I actually did allow Nodes as well by special-casing them. (Haven't mentioned Arrays though, should I?) A web page with an URL should be reentrant, e.g. if you bookmark it and visit it later, it should work. Pages which is dependent on info generated on other pages should either have that info encoded in the URL, or be accessed through a POST request. In the first case, the context is preserved, in the second the page can't (easily) be bookmarked and revisited, since browsers treats pages which is the result of a POST request differently, which avoids the problem of the missing context. Ordinary web sites are usually stateless in the sense that you can visit the pages in any order. Stateful transactions (like payment) are usually handled as a sequence of POST's. Web applications on the other hand are usually very stateful, but precisely because they are usually confined to a single page with a single URL, you dont get the reentrance problem. You can only bookmark the initial state, which is safe. Yes. If an app spans several pages with distinct URL's, but is stateful in such a way that pages are dependent on local state generated on earlier pages, it gets very fragile. We might start to see lots of You seem to be visiting this page out of context messages on Google :-) This is already a problem, even with just cookies. I'm not sure how we can solve it, though. Thats not to say that the proposal is a bad idea. I see some very strong use cases for it. For example, I might have written half a page of text in a CMS, but when i hit save, I'm informed that the network connection is broken, and it wont get fixed before monday. In this case it would be very nice if the client side script could save data in a persistent local store - only accesible to this page, of course. Exactly. This should now be possible with globalStorage[]. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some likeness of DOM Session scope
On Thu, 21 Apr 2005, Robert Sayre wrote: Olav Junker Kjær wrote: Ian Hickson wrote: Anyone have any concrete proposals? :-) http://www.crockford.com/JSON/index.html ? It turns out that the way I ended up defining this, I didn't need to describe the back-end serialisation format. However, JSON does seem like a good candidate for a storage format for people implementing this API, indeed. (Although JSON doesn't support E4X or DOM nodes as yet.) If an app spans several pages with distinct URL's, but is stateful in such a way that pages are dependent on local state generated on earlier pages, it gets very fragile. We might start to see lots of You seem to be visiting this page out of context messages on Google Might be nice to add the ability to tie the objects to a given transaction by associating a POE URI with them: http://www.ietf.org/internet-drafts/draft-nottingham-http-poe-00.txt I looked at this but could not immediately work out how to leverage this idea in the context of HTML5, unfortunately. Do you know if any work is being done on POEs still? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some likeness of DOM Session scope
Ian Hickson wrote: I used this idea for the window.history.pushState() idea: http://whatwg.org/specs/web-apps/current-work/#the-session Let me know if you have any comments. It doesn't cover the bookmark case, only the back-forward case, so I don't think this removes the need for a cross-page-load and persistent local store. You still need something for, e.g. offline applications, and for applications whose sessions are likely to outlive the actual browsing session. For most cases this information might be better dealt with using a session cookie and server-stored data, but I can definitely see some cases (especially games and productivity applications like word-processor-like things) that would require local data storage rather than wanting to depend on the network. I think it is great! Now, what I'd really like to see a solution to the bookmarking problem. Well, it's really not a bookmarking problem, because you can simply do location = #...some representation of the state of the page... And you can bookmark that. The bigger problem is Google. Google afaik completely ignores fragment identifiers. So if f.e. the bookmark location was http://www.example.com/#salesdep;, and everybody is linking to that location, there are 2 problems with Google: 1. Google doesn't support javascript. But it is impossible for the server to send a static page of the sales department, because fragment identifiers are not sent to the server with http requests. 2. Because of the links, Google will add the page to its database, but it will remove the fragment identifier. So even clients with javascript support will see the homepage instead of the sales department page, when they found the page through Google. So what we need is a way to change the path or the query part of the location, without getting a page reload. I think it works best (security etc) to just allow to change the query part. It would probably make the most sense to make this the second argument to pushState. In our example we could do history.pushState(data, salesdep) and get http://www.example.com/?salesdep in the address bar. When Google, or any other non-AJAX client, follows that URL you can let the server generate a static sales department page. AJAX clients get the basic site framework, and the client will read the query string and go to the sales department part. -- Sjoerd Visscher http://w3future.com/weblog/
Re: [whatwg] Some likeness of DOM Session scope
On Thu, 21 Apr 2005, Brad Neuberg wrote: Something along these lines that would be useful is control over what goes into the history (and what affects the back button) and what _doesn't_. Alot of times I shoot off RPC type functions using XmlHttpRequest that I _dont_ want in the history, since they wouldnt be appropriate for the back button, and other times I want the back button to be affected. Ok, I recently added something to the spec that should help with this. Namely, the window.history.pushState() method and the onpopstate= event handler. http://whatwg.org/specs/web-apps/current-work/#the-session The spec is a bit terse right now, but it should address what you mentioned. I'm sure we'll write more developer-friendly docs in due course (like, when it's more stable!). HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some likeness of DOM Session scope
On Fri, 22 Apr 2005, Dimitri Glazkov wrote: Maybe it would a better idea to introduce functionality that standardizes a usability-perfect simulation of a request within the same page? I think that is what Brad is writing about. In other words, instead of trying to come up with a vehicle that allows you to pass data across independent requests, devise ways to: * identify (create) state of an application inside of a page * communicate it to the browser's address bar and history navigation * restore the state when the browser asks for it (via back/forward or bookmark). With this in place, history can be manipulated at will and a transparent user experience of browsing multiple pages can be created within the same actual page. I believe Microsoft has toyed with this concept in IE5 by introducing #default#saveFavorite and #default#saveHistory behaviors. Or maybe it's both: a serializable/deserializable persistence mechanism across independents requests and the way to manipulate the history. I used this idea for the window.history.pushState() idea: http://whatwg.org/specs/web-apps/current-work/#the-session Let me know if you have any comments. It doesn't cover the bookmark case, only the back-forward case, so I don't think this removes the need for a cross-page-load and persistent local store. You still need something for, e.g. offline applications, and for applications whose sessions are likely to outlive the actual browsing session. For most cases this information might be better dealt with using a session cookie and server-stored data, but I can definitely see some cases (especially games and productivity applications like word-processor-like things) that would require local data storage rather than wanting to depend on the network. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Some likeness of DOM Session scope -- Steal Flash's SharedObject Syntax
Flash MX has a scriptable object named SharedObject that can contain far more application state than a normal cookie can, but for Flash movies. Perhaps this is a good concept to steal from Flash? They've thought through the API pretty well. One thing that is unique about these is that they can store binary, so that you can actually serialize the state of your Flash ActionScript (which is just JavaScript now) right into your cookie, making programming in Flash very productive. You can also store images, sounds, video etc., leading to very fast startup time for apps that use these. Some more info on SharedObjects at http://www.macromedia.com/support/flash/action_scripts/local_shared_object/: Local shared objects provide a way to maintain locally persistent data (similar to cookies stored by web browsers). For example, you can create a shared object, such as a calculator with memory, in the player. Because the shared object is locally persistent, Macromedia Flash MX saves its data attributes on the user's machine when the movie ends. The next time the movie runs, the calculator contains the values it had when the movie ended. Alternatively, you can delete the shared object before the movie ends, in which case the calculator opens without any prior values the next time the movie runs. About size considerations: Local shared objects are always persistent on the client, up to available memory and disk space. By default, Macromedia Flash MXcan save locally persistent remote shared objects up to 100 K in size. When you try to save a larger object, the Macromedia Flash Player 6displays the Local Storage dialog box, which lets the user allow or deny local storage for the domain that is requesting access. Make sure your Stage size is at least 215 x 138 pixels; this is the minimum size Macromedia Flash MX requires to display the dialog box. In terms of security, we should be careful that these can't be used as a vector to attack the local system, either through a buffer overflow attack or a way to get a binary image onto a machine that can then be manipulated. One note: when a user clears their cookies we should also clear out these SharedObjects, probably presenting them to the user as super-charged cookies, to prevent a similar security bug that affected Flash. There is a sneaky adware attack called PIE that stores cookies into a Flash's SharedObjects, pulling them back out if a user clears their cookies since Flash didn't hook clearing the SharedObjects into clearing the cookies in the browser. At 07:58 AM 4/22/2005, Dimitri Glazkov wrote: At first, I envisioned a fairly simplistic (perhaps naiive would be a better word) functionality: An initially empty JS object, which survives from request to request until the browser window is closed. This object is implicitly instantiated once per session for each domain, and is the same across all windows/tabs. Being the associative array that it is, the object can be populated by whatever data or functions that need to survive throughout the session. Obviously, you can see some serious potential security, memory usage, and just plain compartmentalization issues here. Then, after reading the thread, it seemed that maybe I am looking at the problem from the wrong end: Maybe it would a better idea to introduce functionality that standardizes a usability-perfect simulation of a request within the same page? I think that is what Brad is writing about. In other words, instead of trying to come up with a vehicle that allows you to pass data across independent requests, devise ways to: * identify (create) state of an application inside of a page * communicate it to the browser's address bar and history navigation * restore the state when the browser asks for it (via back/forward or bookmark). With this in place, history can be manipulated at will and a transparent user experience of browsing multiple pages can be created within the same actual page. I believe Microsoft has toyed with this concept in IE5 by introducing #default#saveFavorite and #default#saveHistory behaviors. Or maybe it's both: a serializable/deserializable persistence mechanism across independents requests and the way to manipulate the history. What do you guys think? :DG On 4/21/05, Brad Neuberg [EMAIL PROTECTED] wrote: Something along these lines that would be useful is control over what goes into the history (and what affects the back button) and what _doesn't_. Alot of times I shoot off RPC type functions using XmlHttpRequest that I _dont_ want in the history, since they wouldnt be appropriate for the back button, and other times I want the back button to be affected. Brad --- Dimitri Glazkov [EMAIL PROTECTED] wrote: IMHO, one of the biggest obstacles for growth in Web applications development is the fact that the entire application lives in the scope of one request. Once next request is made, the browser essentially forgets
[whatwg] Some likeness of DOM Session scope
IMHO, one of the biggest obstacles for growth in Web applications
development is the fact that the entire application lives in the scope
of one request.
Once next request is made, the browser essentially forgets
everything and the whole new cycle of loading, initialization, and
binding begins.
Yes, you can simulate the effect of retaining scope across several
requests with XmlHttpRequest and even frames, but it's the simulate
part that bothers me. Simulate means hacking, and hacking
inevitably means inconsistent and/or incomplete implementations.
It seems that a future Web Application platform should have this type
of functionality readily available. What do you think about the idea
of having some likeness of a scope that's inherently wider than
request?
Consider this example (improvising here):
Request 1:
function SyntaxHighlighter()
{
// code goes here to provide on-the-fly beautification of code
}
document.session.highlighter = new SyntaxHighlighter();
Request 2+:
if (document.session.highighter)
{
var codeSections = document.getElementsBySelector(pre code)
for(var i = 0; i codeSections.length; i++)
{
SyntaxHighlighter.apply(codeSections[i]);
}
}
Is this a totally asinine idea?
:DG
