Hi Jeremy, Some of this has evolved and could likely be cleaned up.
2009/6/1 Jeremy Orlow <jor...@chromium.org>: > First of all, in SecurityOrigin::databaseIdentifier() (in > http://trac.webkit.org/browser/trunk/WebCore/page/SecurityOrigin.h) the > following comment appears: "Serialize the security origin for storage in the > database. This format is deprecated and should be used only for compatibility > with old databases; use toString() and createFromString() instead." This was > done in http://trac.webkit.org/changeset/32597 There are a bunch of problems with SecurityOrigin::databaseIdentifier(), not the least of which is that "_" can't really be used as a delimiter because some intranet host names contain the character in their names. I'd rather we didn't used databaseIdentifier() and had a single string representation we used everywhere. > Despite the comments in the change log, I don't fully understand what the > intention here is. DatabaseTracker and LocalStorage still use > databaseIdentifier() which makes sense since, unless I'm totally missing > something, the toString() format produces file names that are invalid on most > file systems. I don't see why these string representations need to be used for file names. The advantages of the toString() serialization are (1) we need it for postMessage and cross-origin XMLHttpRequest, and (2) we already have an awesome parser for it called KURL. > At the same time, databaseIdentifier omits some of the logic found in >toString (which might be the cause of bugs like >https://bugs.webkit.org/show_bug.cgi?id=20701 ...I haven't confirmed yet). I'll look at that bug once I have Internet access (currently on the train). > So, maybe instead of databaseIdentifier() being "deprecated", it should be > updated to be more like a toString that uses file system safe characters? Late time I looked into this, I was told we couldn't change databaseIdentifier() because users had files stored on their computer that depended on the serialization. > In addition, the creation of SecurityOrigin objects doesn't quite seem > right. There are many places (like in DatabaseTracker) where security > origins are created based on the file, port, and protocol. This is fine when > all you're doing is .equals (which the HashMap's HashArg=SecurityOriginHash > prarmeter does for you), but it seems like it could be inefficient (many > SecurityOrigin objects describing the same origin) and could potentially lead > to bugs (since not all of the properties are serialized during > toString()/databaseIdentifier()). I suspect we can improve this. > It's surprising to me that there isn't one central store of SecurityOrigin > objects (maybe with weak references?) to eliminate the possibility of 2 > SecurityOrigin objects describing the same origin. The problem is that SecurityOrigin objects are mutable. For example, a SecurityOrigin mutates if you set its document.domain property (called "domain"). Also, certain SecurityOrigin objects might be granted certain privileges, and we might not be able to do that if everyone shared the same object. > In general, I suppose I'm just trying to understand the thought behind > SecurityOrigin objects and how they're used in the source code...because it > doesn't seem very natural to me. It might be productive to invent a class "StorageOrigin" or some such that is immutable, and therefore can be shared and moved across threads. That way the storage system wouldn't be tempted to use SecurityOrigin features that don't make sense for storage (e.g., grantLoadLocalResources). Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
