hey guys, so there's been a lot of conversations about Petabridge's role in Akka.NET going forward. In light of what happened with FoundationDB and Apple last week, we thought we'd make it really, really damn clear what we intend to do: http://petabridge.com/blog/no-more-foundationdbs/
OSS all the way
Hey all I was talking with @Aaronontheweb about creating a screencast documenting doing a proper Pull Request from Akka point of view. I was thinking of doing examples this using Git Hub for windows, Git bash and SourceTree. If anyone is interested, since I know @Aaronontheweb has his plate full, to review a screencast script to ensure that I am not missing anything please let me know. My plan is to create a repo for the script , potential diagrams and slides for this project. It will definitely be an iterative process and I want to be as detailed as possible so any input would be welcome. Thanks,
I'm sure folks would be happy to review it once you have a draft up - I'll personally make time to check it out no problem
Is this really the correct way to do this?
protected override void PreStart()
{
var producer = Context.System.GetExtension<DIExt>();
childActor = Context.ActorOf(producer.Props("MyActor"));
base.PreStart();
}Why cant I do this?
protected override void PreStart()
{
var producer = Context.System.GetExtension<DIExt>();
childActor = Context.ActorOf(producer.Props<MyActor>());
base.PreStart();
}
And protobuf package does that when installed
going to push a new version of it and send a PR with it integrated into Akka.Remote so that can now run out of the box
I have created a repo for doing the Pull Request screencasts. It's currently just a skeleton based around contrib document. Each screencast will have their own directory and within each directory I will be putting an outline and a basic script. Once I am able to verify that the script and outline have no issues I will create an initial take and make it available through the repo and probably YouTube. One of the goals of the script and outline are to make it easier for non native english speakers to translate the content and make there own version. Again anyone interested just ping me here. Thanks...
@Aaronontheweb Thanks. I have been doing them for training new employees and getting vendors up to speed of various things for several years. So it's something I am comfortable doing and find that it's very effective along with written documentation. There is no replacement for seeing someone actually do something.
seeing someone actually do something realtime always helps me especially when it's an operational thing
Guys, have you seen this? https://github.com/electronicarts/orbit Bioware have ported Orleans to Java :P
The thing I don't quite get with the Orleans/Orbit stuff, why is the AP guarantees and Actor parts merged together? you might still want AP for Services w/o actor behavior..
IMO, the AP stuff should be in a separate module, and then let you host services/actors/whatever inside it
Hmmm. I don't know. But im not sure if what you are saying is correct. I saw an Orleans screencast a while back, from the Halo team, in which they showed off some Orleans code. And although it all felt like Voodoo magic back then (which became alot more clear since I started with Akka). I do distinctly remember them talking about a Host which took care of all the Distributed and Partitioning stuff.
Or maybe I am misunderstanding what you mean with the 'parts merged together' bits
Ow you mean on a framework level. Hmm. Maybe they felt that that part is, in terms of implementation, so closely married to the Orleans Actor framework, it made no sense to put it in a separate framework. But thats just conjecture on my side, however its the only reason I can think of.
Should be interesting to check out the Orleans code to see if thats true.
Should be interesting to check out the Orleans code to see if thats true.
IMO Akka was always a middleware framework. It is harder to learn and requires an explicit management from the user perspective, but also gives you enough space to develop higher level abstractions (such as streams, virtual endpoints, cluster sharding and many others) on top of it. But you may still dig deep down at any time when you want true control and speed and this is something you'll never get with frameworks, which have started from those higher level concepts as a base line.
Want me to close the pull request?
@rogeralsing @Danthar @Horusiath yeah, that's a design decision with Orleans that I feel is very limiting - the whole thing feels extremely over-engineered to begin with, really. Actors are just tools that don't have any inherent CAP bias, no more than OOP objects having them. Orleans was built for something specific - single apps that are meant to be clustered with high availability.
Orlean's biases don't even really allow for you to network multiple Orleans code bases together without doing some really hacky shit dotnet/orleans#211
so you can't do anything like my WebCrawler Akka.Cluster sample, which uses individual roles as microservices, without having to host your connection to each service in a separate AppDomain
but you know - anything that gets .NET developers in a headspace where they're actively looking at something like the actor model is a good idea in my book