Roadmap - what's next?

[jornh]

Kill CefSharp 1 issues, with resolutions:

• convert to being a valid issue for CefSharp 3
• already fixed in CefSharp 3, can't you use that?
• ?

https://github.com/cefsharp/CefSharp/issues?q=is%3Aopen+is%3Aissue+label%3Acef1+-label%3Acef3+

[amaitland]

I've closed the CefSharp1 PR's. With the CefSharp1 issues, I think we come up with a standard response and stick with it. Clear the decks of old issues. Anything that sounds like it maybe relevant to CefSharp3 we re-label and assign to a milestone where possible.

[amaitland]

I've entered into aggressive issue closing mode, so we'll see what feedback comes of it! 😄

[jornh]

Wow! https://github.com/cefsharp/CefSharp/issues?q=is%3Aopen+ down to two pages, much more manageable! (That link btw has the sum of issues and PRs)

Reeeeally good job there at shaking the tree 👍 🌲

[jornh]

https://github.com/cefsharp/CefSharp/milestones got updated a bit - optimists as we are ;)

[amaitland]

Type for 33.0.3? https://github.com/cefsharp/CefSharp/milestones/33%3F.0.3

[jornh]

Type

Typo? - naah, more like a question: "Will it be 33? ... or something else?"

Renamed to xx.0.3 now https://github.com/cefsharp/CefSharp/milestones/xx.0.3 instead - hopefully more clear

[amaitland]

Makes sense now 👍

[jornh]

Copy over from #504 (comment):

What's remaining for the JsBinding, any criteria for when to merge it?

• Stability
• Needs a thorough review
• I suspect it probably has a few memory leaks that need to be plugged
• Add an [IgnoreAttribute] so methods/properties can be skipped

Should we start maintaining parallel branches like CEF does (e.g. a 2062 one), how many?

I think having a 2062 branch would be nice, though we need to be careful not to overextend ourselves, as it does take a little bit of effort to make sure all changes are merged into every branch with regularity. I think the future branches should be based on JsBinding_WIP as it's the way forward.

What priority does "plumbing"/services like nightly NuGets, x86/x64 split, documenting how to use?

Sorting the split should have a fairly high priority as it's the most drastic change from a user point of view. Once that's sorted we get a nightly NuGet build happening. Then lastly everyone's favorite documentation! lol

Value in adding automated testing?

Would be nice, though I've got no idea where to start. Is the whole multiple AppDomain thing still an issue?

Yep, the AppDomain thing didn't magically disappear. It's also an issue for some users, though there may be other workarounds for them, but at least it serves as a good excuse for not taking a serious look at automated testing

[amaitland]

@jornh At what point do you think we take the training wheels off the Js Binding?

Feature wise it just needs the IgnoreAttribute I believe.

[jornh]

Firstly a big 👍 on 3.0.2, then:

Stability

That's not very actionable (but nevertheless desirable though 😜 ). I only got one case where it actually seems better than master. Just one data point though.

Needs a thorough review

Phew it's a lot of commits. Any idea how to approach it? Areas to focus on? Ways to sample?

I suspect it probably has a few memory leaks that need to be plugged

Got any knowledge, or just hunches? Should we throw some tooling at it?

Add an [IgnoreAttribute] so methods/properties can be skipped

You already covered it 😄

Would polling in the Google Group or encouraging to test help do you think?

[jornh]

We could go as far as writing tests 👯 Could IMO potentially be more fruitful with the bindings and the WCF communication etc. than with visual glitches like the recent WinForms redraw issue.

[amaitland]

That's not very actionable (but nevertheless desirable though 😜 ). I only got one case where it actually seems better than master. Just one data point though.

Thankfully the JS Binding is fairly isolated, if you never register an object, very little of the code actually gets called. The big change in making the browser client the WCF server, which improves reliability in my opinion, as with master there are some major timing issues that are difficult to overcome, as it's not clear when the render process is actually fully initialised.

Phew it's a lot of commits. Any idea how to approach it? Areas to focus on? Ways to sample?

There's about 6-8 core classes, so it's not actually that complex now. A lot of those commits are me bumbling through making c++ changes. I can probably list the core ones if your interested?

Got any knowledge, or just hunches? Should we throw some tooling at it?

Just a hunch, my knowledge of cli c++ is still fairly minimal, so I'm not totally sure on best practice for cleaning up objects. Tooling is an excellent idea, I could download a trial version of dotTrace or something similar.

You already covered it 😄

Got a suggestion on the attribute name? That's the hardest part! lol

Would polling in the Google Group or encouraging to test help do you think?

Can't hurt 😄

[jornh]

I can probably list the core ones if your interested?

Yes please! No promises to how much I can commit to look at right now. But it will enable others to pitch in too 😄 ... and we have a bit of design docco! It could serve as bait/lowered entry barrier for a Google Group post ...

Thankfully the JS Binding is fairly isolated,

Very good point. Let's focus on the WCF role swap. Those who need the JS Binding are those who "pays" for it then TANSTAAFL

[amaitland]

Quick list of classes, I'll try and write something more detailed later.

• WCF IPC
• Duplex communication
• NetNamedPipeBinding

CefSharp.Core

• CefSharp.ManagedCefBrowserAdapter

CefSharp

• CefSharp.Internals.JavascriptObjectRepository
• CefSharp.Internals.BrowserProcessServiceHost
• CefSharp.Internals.BrowserProcessService

CefSharp.BrowserSubprocess.Core (Render Process)

• CefSharp.CefAppUnmanagedWrapper
• CefSharp.JavascriptRootObjectWrapper
• CefSharp.JavascriptObjectWrapper
• CefSharp.JavascriptMethodHandler
• CefSharp.JavascriptMethodWrapper
• CefSharp.JavascriptPropertyHandler
• CefSharp.JavascriptPropertyWrapper

Brief Description
There are three parts to the process

• Registration: When an object is registered meta-data is created in the JavascriptObjectRepository. Complex types are support for properties and the tree will be walked to find all methods/properties.
• Render Process created: The method GetRegisteredJavascriptObjects is called via WCF to obtain meta-data about the bound objects. The meta-data is used to register functions and properties with Cef. Two key Cef classes to note are CefV8Handler for function callbacks and CefV8Accessor for property get/set
• Cef callbacks: the registered CefV8Handler or CefV8Accessor, for which WCF proxies the calls to the JavascriptObjectRepository, where the original object is registered. Simple Action<> and Func<> method calls are made to either execute a function, or set/get a property value.

That's a very high level simplistic explanation, that's missing a lot of detail. I'll try expand upon it later.

[jornh]

Pushing cef.sdk 3.2062.1898 to the NuGet gallery (https://www.nuget.org)...
Your package was pushed.
Pushing cef.redist.x86 3.2062.1898 to the NuGet gallery (https://www.nuget.org)...
Your package was pushed.

cef.redist.x64 3.2062.1898 on its way too ... x86 took 8 minutes on my wifi ... so in about 10 min or so ...

[amaitland]

@jornh Fantastic! Thanks 👍

[jornh]

@amaitland - and anyone else with an opinion 😃 - is it time to take off the training wheels on 2062 and JS Binding WIP and merge into master? Then push another set of -pre packages?

[peters]

@jornh kjør på :)

[amaitland]

@jornh I think so, yes 👍 That green merge button is just waiting to be pressed 😄

[jornh]

Ok press away then!

On Tuesday, November 11, 2014, Alex Maitland notifications@github.com
wrote:

@jornh https://github.com/jornh I think so, yes [image: 👍] That
green merge button is just waiting to be pressed [image: 😄]

—
Reply to this email directly or view it on GitHub
#509 (comment).

[amaitland]

Done 😄

I've updated the ChangeLog, I'll have a go at updating the milestones

[amaitland]

I've tinkered with some of the milestones, probably needs a little more work as I've basically moved everything to 37.0.0.

What does everyone think about cleaning up the branches? Just keep master, CefSharp and 2171?
(Merge 2171-jsb-wip into 2171 to simplify naming)

[jornh]

Just keep master, CefSharp and 2171?
(Merge 2171-jsb-wip into 2171 to simplify naming)

Yes, seems natural to go with that - and maybe keep CefSharp1 too 😄 Ooh that's probably what you meant with CefSharp 😉 I just wanted to be 100% sure!

[peters]

@amaitland

What does everyone think about cleaning up the branches? Just keep master, CefSharp and 2171?
(Merge 2171-jsb-wip into 2171 to simplify naming)

👍

@jornh

Yes, seems natural to go with that - and maybe keep CefSharp1 too

👍

[amaitland]

Yes, seems natural to go with that - and maybe keep CefSharp1 too 😄 Ooh that's probably what you meant with CefSharp 😉 I just wanted to be 100% sure!

Yeah, I meant CefSharp1 😄

[amaitland]

I've cleaned up the branches, down to just three again which is much more manageable 😄

[peters]

nice 👌

[amaitland]

Release is up on MyGet if anyone has time to check the new -pre03 package that would be much appreciated.

I've created a branch on MinimalExample that references the new ones to make life easy 😄

https://github.com/cefsharp/CefSharp.MinimalExample/tree/cef/2171

[jankurianski]

I tested all 3 MinimalExample projects with -pre03 and they are working well 👍

[amaitland]

Thanks 👍 Everything is looking fine on my end as well so I might push them to Nuget

[amaitland]

Packages are on Nuget 😄

[jornh]

Sweet! @amaitland I accidentally saw you even deleted it from the MyGet feed so -pre don't alphabetically overrule the -CI ones 👍

In celebration I added back -pre in https://github.com/cefsharp/CefSharp/blob/master/README.md

[amaitland]

Sweet! @amaitland I accidentally saw you even deleted it from the MyGet feed so -pre don't alphabetically overrule the -CI ones 👍

Yeah, had that problem last time, so though it best to delete the -pre packages once pushed to Nuget

[amaitland]

Anyone have any thoughts on how we should inform users of breaking changes? Notes in the change log? Though I'm not sure that anyone actually looks at the change log.

[jankurianski]

I think the change log is the best place, as it also shows on the releases page (or is that due to you copying it manually?).

We could also give it more exposure on the README.md page that everyone arrives at, like this:

---

...

NuGet Packages

Binary releases contain everything needed to embed Chromium in your .Net/CLR application. For usage see FAQ #8 item.

Upgrading from an earlier version of CefSharp? See the ChangeLog for breaking changes and upgrade tips.

CI Builds

...

---

We can add new sections to the ChangeLog for breaking changes. Then anyone upgrading can scan over these, starting at their old version to the new version, and figure out what they need to fix in their code. For example:

---

...

3.27.0-a0

August 3, 2013, Chromium 27.0.1453.73

• First alpha version of CEF3-based port. Core functionality (normal browsing, back/forward buttons etc) working on WPF. Windows Forms version entirely missing at the moment (not yet ported to CEF3), as well as Javascript integration. [@plundberg]

Breaking Changes

• Change from CEF.Initialize() to Cef.Initialize()

...

---

[amaitland]

I think the change log is the best place, as it also shows on the releases page (or is that due to you copying it manually?).

Manually copy the entries from the changelog when creating a release.

Excellent suggestions, let's run with that 👍

[amaitland]

Probably worth going back over the changelog and backdating any breaking changes that are obvious.

[jankurianski]

I have added some major renames that would hit Cef1 upgraders to 33.1.0-pre01 (and edited the release notes).

[amaitland]

Nice! Hopefully one day CefSharp1 will just be a distant memory! I'll have a scan over the ChangeLog later and see if I can spot anything else.

[amaitland]

FYI I've updated to the new Nuget Restore method, tests ok locally, CI builds.

If anyone has problems then let me know.

https://ci.appveyor.com/project/cefsharp/cefsharp/build/39.0.0-CI751

[roschler]

Saw a comment about Windows Phone above. Did anything ever happen on this front?

[amaitland]

Saw a comment about Windows Phone above. Did anything ever happen on this front?

Comment was about being able to deploy a new version using the web interface, not using CefSharp on a phone.

[roschler]

Ok, thanks amaitland. I'm running WebRTC sessions successfully using Windows Forms and CefSharp on the desktop. I was hoping to do the same on a Windows Phone to establish a video session between a desktop PC and the phone. I'll keep searching.

[rassilon]

I posted to the CefSharp google group asking what folks thought of only supporting VC++ 2013 for CefSharp branches 2272 and later, or whatever CEF branch comes after 2272. I ask because CEF hasn't supported VC++ 2012 for branches >= 1916.

Bill

[rassilon]

This isn't meant to suggest a change in the minimum .Net framework version used in CefSharp.

Bill

[amaitland]

Cool, let's see what people have to say. When VS 2015 is released I'd probably look at supporting that. Personally I think having current and one previous is enough.

[amaitland]

Rather than keep pushing 39 back as new PR's come through I've decided to bump a few to the 39.0.1 or 41.0.0 milestones.

So what I hope is the final 39.0.0 package is now avaliable on MyGet. If anyone has the time to do one last check before we push to Nuget.org that would be greatly appreciated.

https://ci.appveyor.com/project/cefsharp/cefsharp/build/39.0.0-CI847

[amaitland]

Forgot to update build.ps1 to reference 3.2171.2069, so rebuilding packages. If anyone has downloaded, they'll have to clear their nuget local cache.

03e3500

[amaitland]

Updated MinimalExample to use the MyGet 39.0.0 packages

https://github.com/cefsharp/CefSharp.MinimalExample

@jornh @rassilon @jankurianski If anyone has 5mins to take them for a spin that would be much appreciated 👍

[jankurianski]

Checked the 3 example projects in x86 and x64 and they're all working and show the correct Chrome/CEF version.

[amaitland]

@jankurianski Thanks, much appreciated 👍

[rassilon]

I updated to the MyGet 39.0.0 pkgs on my own app, and after having to manually remove the CefSharp/CEF binaries from my Release build directory and rebuild, it seemed to work just fine.

Bill

[amaitland]

Excellent, I've tried with MinimalExample, with x86 and x64 combinations and everything appears to be working fine.

Next step release to Nuget.org

[amaitland]

Packages are now on Nuget.org.

@rassilon Thanks for taking it for a spin 👍

[amaitland]

I've released 39.0.1 to nuget.org if anyone is interested. Nothing too existing in this release.

[amaitland]

For those interested, the updated plan is to skip 41 and go straight for 43. The major rewrite happening on the 2272 branch means that there is still quite a bit of work/testing involved still.