On Mon, Jul 13, 2009 at 10:05 AM, Jeremy Orlow<jor...@chromium.org> wrote:
> On Mon, Jul 13, 2009 at 8:59 AM, Darin Fisher <da...@chromium.org> wrote:
>>
>> On Mon, Jul 13, 2009 at 8:20 AM, Brett Wilson <bre...@chromium.org> wrote:
>>>
>>> On Fri, Jul 10, 2009 at 5:04 PM, Jeremy Orlow<jor...@chromium.org> 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.
Brett
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
