WWDC2003 Session 403

Transcript

Kind: captions
Language: en
well welcome hope you had a good lunch
this session is really critical for
anybody who's going to be who is
thinking of embedding Safari technology
within your own application or
leveraging any aspect of Safari
technology whether using Apple help or
these other things just understanding
what's going on with the Safari
technologies and to talk you through
this stuff I want to introduce Don
Melton manager of internet technologies
at Apple Don thanks John hi there wasn't
that a marvelous lunch mmm still feeling
that ok like John said this is the
Safari overview and I'm Don Melton Lee
internet technologies manager and what
we're gonna do today if I can get that
clicker to work is we're gonna get a
high-level overview of Safari technology
and we're gonna have a roadmap which
hopefully John will remember to read at
the end of the session on other useful
sessions here at the conference
concerning Safari I think this is going
to be especially useful to those of you
developing applications internet tools
web content Apple help content and open
source it's also going to probably be
fun for those of you who might have ever
used a web browser how many of you have
ever used a web browser okay it's a my
kind of crowd then all right ok here's
what we'll cover today like John said
Safari technology you can use in your
software we're gonna see some demos and
I'm gonna talk a little bit about the
api's but remember this is high level
we're not gonna see that much code and
because I'm the manager of Internet
technologies I'm going to remind you
about other internet technologies that
we have available at Apple besides just
the cool Safari stuff so let's get
started talking about Safari everybody's
favorite web browser so Apple released
the first public beta of Safari on
January 7th at Macworld San Francisco
here at Moscone
I knew it was gonna be I knew it was
gonna be popular because people were
trying to download it from the show
floor people were going crazy over this
thing and I think within four days we
set some kind of record for downloads at
Apple it was it was pretty big and then
a few months later we released public
beta to with even more features and the
download rush started all over again
and now this week as you know we've
released 1.0 this is the GM this is the
real thing this it's not a dot next to
it and the folks at the home office in
Cupertino tell me the servers are pretty
busy so why is safari such a phenomenal
success I mean because people are not
just downloading it they're actually
using it and some people are already
even in beta one making it that their
default web browser I can think of three
reasons innovative features solid
quality and impressive performance ok
let's talk about the features Safari is
a full-featured web browser it's grown
up even for a 1.0 release this is just a
partial list of some of the features
with things like snapback integrated
google search and what I think is the
best bookmarks organizer a native web
browser it's very very compelling to
users plus for all us geeks we've got
tabbed browsing
who liked that when we added that in
beta - ok and now bookmarks
synchronization with icing
very very popular the other reason is
solid quality Safari just works right it
works the way you expect it to it
renders web pages the way they were
meant to be rendered it renders them the
way the web designer intended them to be
rendered especially if that web designer
used current web standards but hey
Safari works even if they didn't the
other reason is stability I don't know
how many times after the first beta came
out I heard this is just a beta you
should just stick the 1.0 on that ship
that thing
Thanks we really appreciate that we're
glad the crashes were few and far
between
we'd like to say now that was
intentional we like to think we
engineered that quality so quality is a
big draw and I think this is the other
reason a lot of people are already
making it their default web browser even
back in the beta but the most important
reason I think for Safari success is the
impressive performance I mean it's it's
just the fastest browser on Mac OS 10
not only does it beat the competition in
the standard book benchmarks but just in
everyday usage loading web pages
launch time scrolling and resizing
windows did you notice that one point I
was actually even faster on launch time
than the previous betas worked on that
one it also has a small memory footprint
for those memory challenged
configurations out there so the question
that I hear most often even around the
office is how do we make Safari so fast
and it's actually fairly straightforward
for one thing broken clicker we made
performance the priority the number-one
priority we made it a feature we made it
so that engineers and managers would
have their own job performance measured
on safaris performance I mean we we made
sure that everybody realized this is job
one you have to take it seriously the
other thing is we started with great
technology not only Mac OS 10 as a
platform but also our great open source
engine that I'll be talking more about
later my engineers my Safari engineering
team would like me to mention that we
also started with great engineers so I
didn't have that on this slide ok now
what I think is really important here is
we took regular measurements of the
software we measured it weekly daily
hourly sometimes more often than that
and we measured it across different axes
we've measured page load times and
launch times and memory footprint and
the number of malloc nodes that we had
and week we created massive charts and
tables and we
crack this whole thing and we use the
tools that come right on your developers
CD you know real simple ones like top
and more sophisticated ones like FS
usage and sample and more importantly we
built our own tools and we built them
right into Safari right inside because
if you're not looking at performance
from the inside you're missing a lot of
the picture about what's going on in
your app so we took regular measurements
and then with all that data we remove
the sloth okay we remove those cases of
where we were doing work to three times
to often get it down to just you know
maybe just do that once that's all you
need to do and even in some cases maybe
not even do that at all
and then and only then did we fall into
the classical optimizing just get rid of
the easy stuff off the top and you'd be
surprised at how fast your app can get
with that kind of approach but I think
most importantly we never made it any
slower people always ask me you know how
did you make Safari fast we didn't make
it slow well the truth is we never made
it slower we never regressed if we had
some huge feature that was going to land
and we tested it and tried it out and if
that was gonna slow down the app we
didn't land that feature there was a big
one that was going to go in last year
that would have slowed down Safari by 7%
I told the engineer sorry
can't land that you got to give me that
7% back and he worked and worked it went
a week and a half he got me eight
percent back so I let him land it you
have to do that you have to have that
policy no regressions zero tolerance
that's why Safari is faster on every
release I really like well I have this
bully pulpit where you're all out there
you listening to me after that wonderful
lunch please please some take some of
these techniques back so we can have
fast applications on this platform okay
so so Don Safari is swell for users it
has all these great features the solid
quality this impressive performance but
what's what's in it for us
developers out there your Sam well as
you've probably heard we're opening up
Safari we're opening up the hood and
we're letting you at the engine this
week okay because Safari it's not just a
browser anymore we're taking the
frameworks that we're inside Safari and
we're moving them into public locations
in the system and we're giving them
public api's that you can all call we're
also providing you the developer a
software development kit so you can use
those frameworks and those api's what
are these frameworks they're two of them
the first probably heard about it
already talked about in the conference
is the web kit this is the Safari
content window it's the big HTML widget
it's the framework that provides the
embeddable browser views how you can put
Safari inside your app but there's
another framework our old friend
foundation we've upgraded and enhanced
it with brand-new URL api's for loading
and other things okay so one of these
frameworks available they're available
now yesterday as a matter of fact okay
they're built into Panther and more
importantly they're in Jaguar as soon as
you install Safari 1.0 if you got Safari
one dot oh you know you go in there and
it get info in the finder and notice how
it's skinnier now hey that's because the
engine is out in the system WebKit is
over in the system library frameworks
alongside a new foundation that gets
installed ok so who's using WebKit well
in Panther that's going to be male so
you can have beautiful HTML mail
rendered Sherlock right
and to help viewer and I told you this
is gonna be nice for people doing Apple
help content you've got the power of
safari inside of help in Panther but
also
Xcode will be using it project builder
actually I believe does use it on the CD
and hopefully your application will be
using it one of these days okay
so who's using these new foundation URL
API is underneath well in Panther
software update that's how we download
stuff for software updating you know and
Java uses it for cookies among other
things and hopefully your app can use it
too so when is the SDK available it's
available now right now yesterday as a
matter of fact it went up I believe it
was probably a half an hour after Safari
went online and if you have one of them
free ADC memberships you can just go
right over to the developer site and
download the SDK install that it's got
documentation the whole nine yards total
coverage okay so where can you use the
SDK where can you use these technologies
well you can use them in both cocoa and
yes in carbon applications now it's an
objective-c API but the WebKit has a
convenient C API for initializing the
WebKit and creating views and plus the
SDK has plenty of examples C and C++
adapter code included that you can just
lift and take out using your application
we made sure the license was liftable
and reusable so I'd like to do now is
I'd like to have Richard Williamson
Safari engineer extraordinaire is that
how you introduced him yesterday Scott
yeah thank you come and do a demo of the
web kit for us I don't show that info so
the first time I'm going to show you is
actually a recap of the demo yesterday
and so some of you may have seen it
already I want to put out one thing the
the controller that we use isn't on the
seed of the Penta CD so keep that in
mind the first demo we're going to build
a codeless browser that's what it's come
to be called so I'm gonna watch
interface builder and start a new
application and you'll notice that
interface builder has a new palette the
WebKit palette I'm going to place an
instance of that class the webview into
my window and now I'm going to connect a
URL to this webview using target action
and two buttons quickly go back and
forward
get these buns a label and connect them
again using target action let me set the
resize flags on these buttons and then
we will test the application without
compiling any code without writing any
code it really is this easy-to-use web
kit so what like what I'd like to show
you now is a demonstration of the binder
technology which I showed you yesterday
but it's worth a second shot so the
first thing I'm going to do is
disconnect the normal target action
mechanism that we use to connect the
text field to the webview and instead
I'm going to use a controller a web view
controller to bind the webview in the
text field together to the same
underlying property the main flame URL
so when the URL changes in the webview
it will be reflected in the text field
and to do that I'll use the new bindings
inspector after selecting the webview
can the text field and I'll bind the
value of the text field to the main
frame URL
now I'd also like to enable and disable
the back forward buttons as I navigate
and as it's appropriate to enable and
disable these buttons so I'm gonna bind
or associate the enabled property of the
back button to whether or not the
webview can go back and similarly can go
forward
now finally what I'd like to do is add a
Clovis indicator so I can see when the
page loads and when it finishes so let's
add a Clovis indicator this size this
text field so it fits and we'll make the
focus indicator determinate from 0 to 1
and bind it to the estimated progress of
the page load set the resize flags
that's it again no code the code list
browser let's go ahead and run this now
you'll notice the back and forward
buttons are disabled the focus indicator
showed the page load and as I navigate
the URL of the text field changes so
that's the quick snapshot of how to use
WebKit from Koko but I've already had
questions about how do we do this from
carbon so what I'm gonna do now is show
you a couple of applications that
already build these applications with
their source code in their entirety or
available in the SDK as examples so the
first example is an application called
carbon web and this is a browser written
using the Carbon api's just to show you
that it is no different than the cocoa
version let me load a web page
there you see and it's relatively
full-featured it has a history it has
back and forward buttons and final demo
I'd like to show you is another carbon
application this uses a combination of
WebKit and new foundation api's to
download URLs onto your desktop let me
go ahead and load a page as simple as
that
so this sample is also an SDK all the
source codes available to you thanks Don
thank you Richard well you'd think it
was that easy to do a web browser we
could have got Safari done sooner huh
yes those guys have been sandbagging me
all right rich will be back he's here
all week and yeah he has a session which
is a lot more in-depth on Friday morning
at 9 o'clock right okay let's give you
an overview of the WebKit right now
first off I want you to look at this
incredibly simple architectural diagram
okay but really the WebKit is that
simple I mean Safari sits on top of the
WebKit and he uses the WebKit to display
web content the WebKit sits on top of
the foundation URL API and it uses that
API to load web content and it's really
not that much more complex and Safari
itself is in a way just a wrapper for
the WebKit but let's focus on the WebKit
for now and let's take a look at what's
inside it two special frameworks webcore
and javascriptcore our two open-source
components our engine I'd like to talk a
little bit about those at the core of
WebKit what we're doing is we're using
open source from the KDE project now the
KDE project is a desktop environment
available on Linux and other unix-like
says and the KDE
top has various applications and
utilities and libraries in it and one of
those applications is the conquerer web
browser and the conquerer web browser
uses two libraries in KDE called HTML
and KJ s and we're using those same
libraries web core is basically an
adapter built on top of K HTML HTML is
the HTML rendering portion and web core
not only contains about you know 98% of
the KHTML source but it also contains
adapter glue code basically to connect
it to the app kit and OS services and
everything else underneath the other
framework is JavaScript core JavaScript
core is just basically a thin wrapper
around KJ s and JavaScript Corp is a
JavaScript interpreter it's the part
that gives dynamic content to webpages
now we also have some other open-source
components in webcore and javascriptcore
including the XX pad XML parser the pcre
regular expression library and believe
it or not we've even got some Mozilla
code in there that always surprises
people when I tell them that it's not
much but we do add Mozilla code in there
so why did we choose to do the engine
open source well it's all about the
technology I mean this open source is a
great development model you get lots of
people working for you essentially for
free you get lots of contributions from
the outside and you you get synergy
going with a whole community but for us
the decision to use HTML and kgs was a
technology decision they're that good
and I'd like right now just a tip my hat
to the KHTML and kgs developers in the
KDE project and thank them for their
wonderful work
and you really appreciate it at Apple
because let me let me drill down this a
little deeper it's small KHTML and KJ s
combined are only about a hundred and
forty thousand lines of code that's less
than an order of magnitude smaller than
some other web browser engines out there
that's that's a lot less code and it's
fast not only is it fast because less
source code makes less object code and
if you actually get less object code
well you go faster but it's just
designed to be fast from the get-go it's
a really good design well one of the
things I really love about it is it's
easy to modify this is a fun code base
to hack it's just very straightforward
easy to understand C++ code you'd love
it
so what are we doing with the community
the open source community with K HTML
and kgs well we're working with the KDE
team we've already had one transatlantic
telephone conference call with them
we're on mailing lists together and
Harry Porton who's the lead for kg/s has
actually been out to the Cupertino
campus and visited us we know these
people we know them pretty well they're
very nice folks we're also giving back
our bug fixes enhancements to the
community apple is giving that back if
you notice yesterday one of the other
downloads you could get is you get the
latest version of webcore and
javascriptcore because hey it's
open-source give that back and we've
actually been sending patches along the
way back to the KDE team and we're also
taking contributions from them just just
a 3-4 weeks prior to us releasing 1.0 we
actually took a patch for a very small
feature in KHTML itself from the KDE
trunk we're also sharing ideas and plans
for the future with the KDE developers
like I said about our previous summit
we're going to have another one now that
the Safari team has survived Safari one
point
once we survive WWDC we're planning on
getting together again and figuring out
what we do next how to split up some
work and really take the engine toward
the future but you can contribute to to
this engine either to our webcore and
javascriptcore projects or to Kage to ml
and kgs we would love to see your bug
fixes and enhancements too so which
frameworks should you use though I mean
because I've been talking up webcore and
javascriptcore here how they're great
don't call them directly their internal
frameworks they're api's are guaranteed
to change in fact David Hyatt must have
changed in this afternoon knowing him
don't use webcore and javascriptcore use
the WebKit the WebKit is the public API
for webcore and javascriptcore
technology okay so what does WebKit
provide let's get back to it as a whole
okay basically the WebKit provides core
classes to display web content and
carbon and cocoa windows it can display
by default mime types like HTML text and
images but also things like plugins and
Java applets it simplifies the
complicated loading process it can
request content from a server and
download that in the background and
manage the delivery to your application
plus it not only deals with the internet
it can deal with local files as well it
also has a default behavior just like a
web browser yep if user clicks on a link
with the default view you saw in
Richards demo it just loads another page
WebKit will create manage all the views
destroying what it needs to cleaning
things up behind your back it's got you
covered so why use it well
many applications need to display HTML
content not just web browsers certainly
web content editors for preview but even
word processors and spreadsheets and
apps that I can't even think about yet
but more importantly why right
code to do this yourself I mean it's a
lot of code but we built it in the
system we've made sure that it's
optimized it's fast it's got a low
footprint it's not going to add to your
startup time to call it it's right there
at your fingertips as developers okay
another reason to use WebKit is the fine
standard support we are fully buzzword
compliant
we got your HTML for your XHTML your XML
your CSS one two and even some a css3
Dom level zero Dom level one Dom level
two I mean even if you don't know what
all those means it it does sound
impressive I hope we support HTTP
cookies javascript net netscape style
carbon-based plugins java applets secure
connections over ssl and for your text
geeks out there we do unicode and
bi-directional layout support so we're
fully that's a lot of rfcs and w3c
specifications they just named off their
but more importantly we're we're real
world compliant because the WebKit knows
how to layout the world weird web okay
because you know I don't know if you go
to some of those dark corners of the
Internet where you know it's just about
one two grades above line noise out
there the WebKit can handle it it can
handle that malformed content as well
but because there's so much of that
stuff out there we're working with the
w3c on new standards we want to make it
better for web content developers out
there we have team members on w3c
committees we're committed to this for
the future okay I want to cover some
basic WebKit concepts four concepts
views frames loading data and delegates
okay first off infuse how do you embed
web content in your application well you
create a web view object you attach it
to a window and then you send its main
frame a load request message
it's that simple webview inherits from
in s view just like other coco views and
if you're using it from carbon it acts
like an H I've you it provides a no code
interface you saw that in the interface
builder demo and it has plenty of hooks
for customization which we'll discuss
shortly frames a web frame encapsulate
the data displayed and a web view okay
every webview has at least one web frame
and load requests are sent to this main
frame as I mentioned earlier web freight
web frame objects are created by the
webview it manages them all for you and
web frames can be nested in a hierarchy
you know sort of like frame sets on the
world wide web and web view manages that
and the route frame is called the main
frame that's where you send your load
messages to loading data loading data
into frames is handled by two foundation
classes new foundation classes and as
URL request in nsurlresponse--
a request is just the URL to load and
any options on that load options like
whether it should use the cache whether
it should reload what the user agent
string is things like that and a
response is everything from the server
except the content this is the metadata
like the HTTP headers you know times and
other tricky little information there
delegates now this is where I think the
real cool part of web kits is delegates
are how you customize the embedded view
think of delegates like callbacks if
you're a C programmer basically excuse
me you create a delegate object that
follows an informal protocol or an
interface and you pass and you attach
that object to the web view to handle
things for you there are four delegates
for web views the first one the web
frame load delegate the
chat attracts changes to what page
you're on for example when a page starts
loading it stops loading it fails to
load and it tracks the transitions
between pages the next delegate is the
resource load delegate and this tracks
the loading of sub resources on the page
for example images you could create one
of these delegates if you wanted to
block images or you wanted to load a
completely different image than the one
the page specified you might implement
both of these delegates if you wanted to
do progress feedback and if you look at
the source code to one of the examples
we have on the disk that's actually
what's done for progress feedback the
third delegate is the policy delegate
this handles navigation actions like
clicks and form submissions and back and
forward and you can basically with the
policy delegate either handle a let
WebKit handle the content internally or
maybe you want to intercept that click
and say I don't want to download you at
all I'm not going to allow the user to
click on that link or maybe instead of
loading it within your app you want to
download it to the desktop you could say
download that instead of displaying it
then there's the web UI delegate that
manages all window and user interface
activity it controls the opening of
windows and you can actually use it to
control context menus as well like add
items to context menus and any
application that's going to handle web
views and multiple windows is probably
going to want to create a web UI
delegate and I'd like to call Richard
Williamson back up to the stage to show
you a demo of that very thing
okay so you see the codeless browser now
we're gonna make some code you three to
get through this presentation without
seeing any code we have some code we're
gonna write right now and what I'm gonna
do is show you in Xcode one of the
sample applications that is on the SDK
and we'll modify it so we first run it
to show you some of the features now
you'll notice that this mini browser has
a few additional features than the the
codeless browser up in the title bar i'm
showing the number of resources that
were loaded 43 or 43 that was done using
the resource load delegate you also
notice that in this case as I navigate
the uol does update in the text field I
didn't use the controller technology I
didn't bind the URL to this field I used
the delegate to set that with code as
glue code to do that and that glue code
is visible in the SDK now the let me go
to the new york times site and show you
some of the built-in context menus that
the WebKit has in this case open link in
new window download to disk and copy
link to clipboard now by default the
WebKit will show this context menu but
there's no implementation behind it it's
your responsibility is a client of
WebKit to open a new window with your
chrome and your instance of webview and
in fact it might not even be a window
you could change the title of this
context menu and you may open a link in
a tab for example but in this case let's
go ahead and try and open the link
nothing happens
that's because the UI delegate isn't set
up to handle a new window let me go back
to Xcode and if I can get a handle on
Xcode let me bring up the editor
and open up the source for the document
now this document is using the NS
document infrastructure and you can see
that I'm setting up two delegates the
same load delegate and the resource load
delegate these are the two delegates
that handle showing that progress in the
title and changing the URL what I'd like
to do is add a UI delegate so I'm going
to cut and paste this code that happens
to be down here just below and add
myself as a UI delegate now the API for
these delegates is really rich but I
want to emphasize by default you don't
have to implement anything it's default
behaviors for all of the delegate
mechanisms so I'm just going to override
one method this is the method that we
use to create a new view so WebKit will
send this in response to requests either
from the context menu or perhaps from
JavaScript to open a new window and what
I do here simply is to use the NS
document infrastructure to create a new
document using the standard document
controller that will open a new untitled
document which in turn will load a nib
file that nib file contains the webview
that you can see I retrieved from the
document down below and then simply I
load the request into the mainframe of
that webview that's all it takes
let's go ahead and compile this yes I'd
like to save and once it's compiled in
link let's run it
so let's try different site how about
wired okay now if I bring up a context
menu over a link and open the link in a
new window
I get in your window simple as that
that's it so there's a lot more detail
that will show you on the session on
Friday but this gives you a sense of how
to use delegates and the WebKit next
time thank you Richard oops okay click
on the demo button okay I'd like to give
you a little overview of the foundation
API and let's go back to one of those
simple architecture diagrams once again
Safari and WebKit at the top foundation
in the middle and I just want to focus
on the fact that foundation the URL API
sits on top of CF network that's where
it gets its implementation and that sits
on top of BSD sockets okay let's focus
on that API very very simple stack
standard stuff okay so what does
foundation now provide whatever you
added URL loading one thing we've
already talked about that a little bit
but also content caching so you can get
fast access to web pages and other
internet data cookies so you can do all
the sorts of e-commerce and complicated
web application work authentication so
you can get into the sites securely and
custom protocols you can add your custom
protocols now so why use this API well
the features I just mentioned before the
convenience because it does a lot of
work for you flexibility much like the
WebKit it's very very flexible and the
performance even better than before so
let's talk about the convenience first
just like the WebKit the foundation URL
API has smart default behaviors just
does the right thing for you by default
it has automatic handling of cache and
cookies if you're going to write a
little command-line tool to download
URLs guess what you
got the power and behaviors of an entire
web browser behind you if you want it
our cache works per application and you
can decide where that's stored on the
system if you don't decide a nice
default spot is picked for you and
cookies are per user but their shared
I'm sorry they're there per user but
they're shared across applications and
it also has nearly automatic handling of
authentication if you want to get basic
and digest auth things like that all you
have to do is just implement two
callbacks basically two delegates for
flexibility it has methods and delegates
to control just about everything request
options that I mentioned before things
for reload and offline modes you can get
very clever there you can get direct
access to the cache if you want and if
you want to get funky with a cookie
manager you can make multiple cookie
policies just like Safari has you know
always accept always reject you can do
an ask policy if you want plus we allow
you to add custom protocols we provide
the standard HTTP HTTP FTP file and the
all-important about protocol but you can
add your own using the same API that
we've used but the performance if you
thought it was fast before in Jaguar
it's even faster now fast URL loading is
essential to fast web browsing and we're
going to keep making that better so let
me cover some other internet
technologies since we've got through the
web kit in the foundation URL API is
that I want you to know about and before
I move on to this I just want to mention
one of the session tomorrow when I was
talking about web standards I've forgot
to mention there'll be a session 10:30
tomorrow morning Safari and technology
and web standards I have no idea what
room it's in but John Glenn's Eno's okay
so the first technology I want to talk
about CF networking see if network we
like to call it all the networking knobs
and buttons it has a nice corefoundation
style capi don't forget about that
that's what's underneath the foundation
API that's what foundation is
implemented on top of it has protocol
abstractions for sockets for HTTP even
for rendezvous and in Panther we're
adding DNS host resolution and support
for the FTP protocol also we have a web
services API this is how you do XML RPC
and soap on Mac os10
and in Panther we're adding a
server-side API also Sherlock the easy
way to deliver platform compelling web
services I like to call it web services
for the rest of it rest of us excuse me
what's new in Panther we've added a
channel browser like Safari bookmarks
it's a whole organizer not only does it
contain the standard Apple channels but
it can contain your third-party channels
we've created also a new easy channel
submission mechanism and we think this
will give you a high visibility for your
web service in Sherlock we've also
improved performance dramatically faster
launch and channel switching it's very
peppy and we have a new standards
compliant xquery engine it's two to
three times faster than the one in
Jaguar ok let me cover just very quickly
some other technologies that maybe you
shouldn't use anymore these are no
longer under active development HTML
rendering lib no use the WebKit that's
why we put out the whole Safari SDK
nsurl handled well it still works and
has been re-implemented on top of the
new foundation api's it's not where the
future is URL access manager please say
no please use CF network for some of the
low-level operations and the new
foundation URL API is for everything
else also internet config you don't
really need to use it anymore launch
services can can set up those helper
applications and system config can be
used for just about everything else ok
in summary just to make sure everybody
got it or they came in late don't forget
the WebKit can put a browser view in
your application and foundation now has
upgraded URL api's at your disposal so
please create some great applications
using these technologies for Mac OS 10
things nobody has ever seen before
that's what will really thrilled the
Safari and the Internet technologies
teams thank you very much and like to
bring John Valenti back for the wrap-up
John it's dawn 3 why don't we call the
Q&A panel up well we're getting roadmap
there ok but while we're going through
the Q&A folks all right so for the for
the benefit of those who would be
watching this session on DVD someday
there was a session this morning open
source at Apple there's a pile of other
sessions that are coming up later this
week or later today related to internet
technologies at Apple so Safari
technologies and advance foundation URL
advanced WebKit api's later on this week
delivering web services using web using
Sherlock channels and then overview of
networking API so it's really important
in the age of Panther to make the right
networking API choices as well as a
variety of other API choices there are
the right API is to choose in the wrong
API is to choose nowadays so a lot of
these sessions are going to be great for
giving you that kind of guidance and
finally if there's any feedback you have
on the API is related to you know
foundation URLs or WebKit or anything
you've heard in this session that you
want more information about or you know
working with Apple in the Safari
technology side of the house feel free
to send me an email and we'll I'll get
you plugged into the right people
you