CoreBase: necessary additions for WebKit

[Daniel Ferreira (theiostream)]

Hi Stefan,

I don't know if you've been following the list for my huge thread on a
TODO list that GNUstep needs to implement for WebKit[1], but among
those items are some related to CoreBase. I've scratched the surface
of how to implement some of them but I'd like your two cents before I
start working on it and possibly screw things up.

In order of priority from first to last, these are the issues:

1) Implement -[NSRunLoop getCFRunLoop]
This one is really, really needed for WebCore to set up a lot of stuff
-- and is the only one in this list we can't live without.

I can think of solving this by creating a category to NSRunLoop in
CoreBase that implements this method by creating a new CFRunLoop with
all sorts of information we can gather from the receiving NSRunLoop. I
don't know if any bizarre issues will arise, though. Does this seem
sane?

2) Implement CFNotificationCenter
We need CFNotificationCenterRemoveObserver() and
CFNotificationCenterAddObserver() for WebCore edge cases. I would be
tempted to follow the model of some current "classes" and forward
these functions' behavior to NSNotificationCenter, but in this case
(per the Apple documentation) the classes would not be toll-free
bridgeable, so I don't know if relying on the Base implementation
would be okay.

If we *can* use Base, that's great, but if we can't, I'd like to know
how you'd implement these functions. Also, is there any particular
reason why you did not implement this?

3) Implement CFPreferences
We need CFPreferencesCopyAppValue(), CFPreferencesSetAppValue(),
CFPreferencesAppSynchronize(). Once again, if I could just rely on
Base I'd use NSUserDefaults, but since this is not a
toll-free-bridgable class (or a class at all), I wonder if that's
"legal".

The same question applies here: if we can't use Base, how would we do
this? Note: for WebKit purposes, we don't need to access any
non-app-specific user defaults, so this reduces the scope of the work
that is currently needed.

We can live without this because we can change WebKit not to look for
preferences and just assume the default.

4) Missing CFLocale functions
I suppose I can figure out the Unicode functions in CFLocale by myself
to add the new functions needed by WebKit. I'll send a pull request
with it in the near future.

The same for preferences goes here -- we can mostly keep these
functions unimplemented and assume the default. These are particularly
needed by JavaScriptCore.

5) CFStringTokenizer
We lack CFStringTokenizer, which is used by WebKit if it is on iOS,
but since that's not the case of our build we can leave that alone for
now.

Aside from these ones, I am almost sure we'll need to do some
bugfixes, but nothing that I can anticipate right now.

Also, please let me know if there's any issue you'd like to work on so
I can focus elsewhere :)

-- Daniel.

[1]: http://lists.gnu.org/archive/html/gnustep-dev/2017-06/msg00040.html

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

On 30 Jun 2017, at 21:46, Daniel Ferreira (theiostream) <[hidden email]> wrote:

>
> Hi Stefan,
>
> I don't know if you've been following the list for my huge thread on a
> TODO list that GNUstep needs to implement for WebKit[1], but among
> those items are some related to CoreBase. I've scratched the surface
> of how to implement some of them but I'd like your two cents before I
> start working on it and possibly screw things up.
>
> In order of priority from first to last, these are the issues:
>
> 1) Implement -[NSRunLoop getCFRunLoop]
> This one is really, really needed for WebCore to set up a lot of stuff
> -- and is the only one in this list we can't live without.
>
> I can think of solving this by creating a category to NSRunLoop in
> CoreBase that implements this method by creating a new CFRunLoop with
> all sorts of information we can gather from the receiving NSRunLoop. I
> don't know if any bizarre issues will arise, though. Does this seem
> sane?

I suspect that this will probably not work, because the bridging expects the two runloops to coexist.  Ideally, we’d have a libdispatch-based implementation of both NSRunLoop and CFRunLoop and each would then be a fairly thin wrapper around the underling dispatch queue.

> 4) Missing CFLocale functions
> I suppose I can figure out the Unicode functions in CFLocale by myself
> to add the new functions needed by WebKit. I'll send a pull request
> with it in the near future.
>
> The same for preferences goes here -- we can mostly keep these
> functions unimplemented and assume the default. These are particularly
> needed by JavaScriptCore.

Note that the POSIX 2008 xlocale extensions (which are now widely supported because the locale stuff in C++11 is ) were designed by Apple to implement most of this functionality in libc, so they should be relatively easy to implement now.  It would actually be very nice to reimplement a bunch of the NSLocale stuff in terms of locale_t as well now.

David


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev

[Daniel Ferreira (theiostream)]

Stefan wrote:
> That seems reasonable. The only problem you'll probably run into is that, from my understanding, NSRunLoop is built on top of CFRunLoop, and trying to go the opposite direction might prove difficult. For example, it is not immediately apparent to me how each iteration of the loop would be run. I assume Apple simply adds observers, sources and timers directly to the CFRunLoop inside the NSRunLoop.
> Additionally, I did not write the code in CFRunLoop, and I'm only vaguely familiar with it. I think it was the author of Darling (for the life of me, I cannot remember his name, now) so you probably want to direct your question to him. CFRunLoop was one of the types that are over my head. I understand how to use it, but not how to implement it.

David wrote:
> I suspect that this will probably not work, because the bridging expects the two runloops to coexist.  Ideally, we’d have a libdispatch-based implementation of both NSRunLoop and CFRunLoop and each would then be a fairly thin wrapper around the underling dispatch queue.

I assume GS has some internal logic for NSRunLoop's implementation. I
haven't looked into it (and will probably only do in the course of the
next weeks), but would it seem reasonable to make CFRunLoop a wrapper
around this same implementation and use this to make NSRunLoop and
CFRunLoop share the same resources (i.e. same internal data structs
etc.)

This would require rewriting a good part of CFRunLoop, but it seems
more approachable than expecting Base's NSRunLoop to depend on
libdispatch.

Once again, I really haven't looked into it, so this may be totally
off. Just wondering whether there would be opposition even to this
basic idea.

> Note that the POSIX 2008 xlocale extensions (which are now widely supported because the locale stuff in C++11 is ) were designed by Apple to implement most of this functionality in libc, so they should be relatively easy to implement now.  It would actually be very nice to reimplement a bunch of the NSLocale stuff in terms of locale_t as well now.

It is exactly CFLocaleCopyPreferredLanguages() I'm talking about ;)
This is not a priority for me since I can adapt WebKit to assume en_US
or something like that as a default, but good to know a viable
implementation can be done. On the medium term, I may look into it.

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

On 1 Jul 2017, at 22:51, Daniel Ferreira (theiostream) <[hidden email]> wrote:
>
> This would require rewriting a good part of CFRunLoop, but it seems
> more approachable than expecting Base's NSRunLoop to depend on
> libdispatch.

Note that an increasing amount of Cocoa code depends on at least the main runloop having a libdispatch queue, and libdispatch runs on all GNUstep-supported platforms (including Windows - there are multiple ports, and Microsoft maintains one, though I also talked to that team a few months ago about reimplementing the libdispatch APIs on top of the Windows concurrency primitives).

David


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev

[Richard Frith-Macdonald-9]

> On 2 Jul 2017, at 10:07, David Chisnall <[hidden email]> wrote:
>
> On 1 Jul 2017, at 22:51, Daniel Ferreira (theiostream) <[hidden email]> wrote:
>>
>> This would require rewriting a good part of CFRunLoop, but it seems
>> more approachable than expecting Base's NSRunLoop to depend on
>> libdispatch.
>
> Note that an increasing amount of Cocoa code depends on at least the main runloop having a libdispatch queue, and libdispatch runs on all GNUstep-supported platforms (including Windows - there are multiple ports, and Microsoft maintains one, though I also talked to that team a few months ago about reimplementing the libdispatch APIs on top of the Windows concurrency primitives).

While, for many years, GNUstep has had a policy of minimising external dependencies (because a common complaint was that it was difficult to install, and we wanted to minimise instrallation problems), I really don't like sending time working on or maintaining code when someons else is doing it and we can leverage their work.

In that spirit, I'm very much in favour of using libdispatch where it's available and as efficient as (or better than) existing code. Of course using it without breaking existing code may be a challenge...  In particular I worry about breakage on windows since libdispatch, like the I/O and event APIs in Foundation, was not designed with portability to windows in mind.  It's good to hear that windows ports exist.
_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev