[Webkit-unassigned] [Bug 27899] [Gtk] Expose a database API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=27899





--- Comment #6 from Martin Robinson <martin.james.robinson at gmail.com>  2009-08-15 15:40:28 PDT ---
Thanks for the great feedback, Jan!

> I think it's best if we move the database stuff out of SecurityOrigin and move
> them to WebDatabase. Is that more realistic or developers really should expect
> that SecurityOrigin should know about database quotas and such?

In this case, I followed the design of the Mac and QT ports which expose this
functionality as methods on a security origin. I'm certainly not opposed to
moving it elsewhere. :)

> Also I'm not sure if we should copy WebHistoryItem here. WebHistoryItem was
> meant to be shared between the WebBackForwardList and a future WebHistory. Does
> WebDatabase/WebSecurityOrigin have the same semantics? 

Really, the issue in this case is that I haven't figured out a good way to
manage the lifetime of WebKitSecurityOrigin and WebKitWebDatabase. I'm using
the hash in this case to prevent them from being allocated needlessly if they
are required twice. I haven't figured out a way yet to keep them from leaking.
This is probably the main reason I haven't marked this patch with r?.

> webkit_security_origin_get_databases -> webkit_database_from_security_origin?
> Also, we currently don't provide an API for the internal name so I'm not sure
> if it's worth mentioning here.

The other ports don't expose a method like this, so I've made it private and
renamed it to something like what you suggested. This should also prevent the
problem of trying to create a WebKitWebDatabase for a non-existent database. I
didn't see a great way check manually in WebCore, but perhaps I missed
something.

> I think we need to distinguish between web_database and just database. Or maybe
> just rename database to databases (or something like that) to signify multiple
> databases?

I'm not sure I understand this.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.