On Mon, Jul 13, 2009 at 10:08 AM, Brett Wilson <[email protected]> wrote:
> > On Mon, Jul 13, 2009 at 10:05 AM, Jeremy Orlow<[email protected]> wrote: > > On Mon, Jul 13, 2009 at 8:59 AM, Darin Fisher <[email protected]> > wrote: > >> > >> On Mon, Jul 13, 2009 at 8:20 AM, Brett Wilson <[email protected]> > wrote: > >>> > >>> On Fri, Jul 10, 2009 at 5:04 PM, Jeremy Orlow<[email protected]> > wrote: > >>> > WebCore::String has the interesting property of differentiating > between > >>> > an > >>> > empty string and a null string. In string16, however, there is no > such > >>> > thing > >>> > as null. > >>> > The LocalStorage implementation I'm working on proxies data between > the > >>> > rednerer processes and browser process. Some of this data is in the > >>> > form of > >>> > WebCore::Strings that need to differentiate between empty and null. > >>> > I could add a boolean to all IPC messages where the string could be > >>> > null and > >>> > then add explicit checking (rather than using the elegant and > implicit > >>> > type > >>> > conversions that normally happen from WebCore::String <-> > >>> > WebKit::WebString > >>> > <-> base::string16) but that seems pretty ugly. I think a better > >>> > solution is > >>> > adding a new type to base, adding serializing code to > >>> > common/ipc_message_utils, and adding implicit type conversions > between > >>> > WebKit::WebString and this new type. > >>> > First of all, is that a good idea? Second of all, what would be a > good > >>> > name > >>> > for it? NullableString16? > >>> > >>> What is happening with Darin's WebCore interface stuff. I remember he > >>> was planning on having some kind of WebString that could be passed to > >>> IPC. Is this still the case, and can we use that instead? > >>> > >>> Brett > >> > >> WebString exists (has for many moons now). It is just a wrapper for > >> StringImpl, > >> the same way WebCore::String is. It is not threadsafe due to the > >> reference > >> counting done for StringImpl. That makes it a very bad candidate for > >> serializing > >> via Chrome IPC. Someone might naively handle such an IPC on the IO > >> thread, > >> and then PostTask the WebString to another thread. We could try to > solve > >> that > >> using assertions, but I decided instead to avoid serializing non-POD > >> WebKit API > >> types over Chrome IPC. > >> For reference: > >> > >> > http://src.chromium.org/viewvc/chrome/trunk/src/webkit/api/public/WebString.h?view=markup > >> -Darin > > > > I guess what I'm proposing is that we have a string data type that can be > > safely passed across IPC but that has all the possible states a > > WebCore::String does. I believe adding the null state is the only thing > > missing. > > In my code, I've worked around this by passing a boolean along with the > > string16 which states whether the string is null. This will work, but > since > > AppCache, Database, and maybe others will soon be passing WebStrings > through > > the IPC layer to their backends in the browser process, I'd > be surprised if > > this doesn't come up again. > > Yes, I think NullableString16 is better than passing a separate bool. Can anyone think of a better name for it? --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
