RFC
As suggested some weeks ago, here is a non-implementation based approach to explain the AF.
Until today, it is only a rough draft still unformated. If you find typos, you may keep them
I'm planning on amending this presentation with an explanation of messaging schemes and further refining
Please feel free to comment and to quote in your own documents.
Oli
Update: included messaging schemes, but still no formatting or fancy graphics. No further updates scheduled before returning from holiday beginning of Feb
Version 5: content / wording revised, added some graphical representation, some more strange examples based on this ppt; there will be a session on the German VIP days (Oct. 23rd 2013)
Version 6: included community feedback. Thanks a lot!
Version7: pptx as used for presentation at the German VIP days. Feedback I got: the presentation title is a bit misleading, the audience really expected an AF implementation on a real-world application, so I'll probably rename this for future versions. Changed Actor / Subactor view for the synchronous messaging example.
Version8: changed title along with some updates for clarification
Hi Oli
Great analogy. I love it
P.S. It may a bit harsh to fire the Sub Actor ... Couldn't he just be a consultant?
Patur
Well... my colleague who went through the presentation gave the following feedback:
"Now I know, I'm a sub-actor looking forward to the idle state. Unfortunately my task scheduling is not working properly still I'm hoping not to get unloaded because of this"
I think he got the gist of the matter
Wow, this was very funny! And also a good example, thanks!
Nice document. I dont understand what you mean by "By training, they can be extended", on the "Training" slide. What do you mean by training? Do you just mean that methods can be added to Actors in order to give them abilities that they need to do their jobs? Also, when you say "Extension can also be achieved by delegation", do you mean that if an Actor does not have an ability needed to fufill a portion of a job, that Actor can delegate that task to a different Actor (by instantiating it)?
You're right. I meant training in the sense of adding methods.
The delegation stuff is going to be described a little more detailed in one of the next versions of the document. Still thinking of a way of how to describe this in a simple manner.
Oli: Thank you for writing this up. Documentation written from a fresh point of view often makes the product as a whole accessible to a wider range of users.
Thanks for the positvie feedback. I'll continue workning on this document and post it here!
I look forward to the updates - this is a very accessible introduction to actors.
Shameless plug - see an implementation of the coffee shop in AF that was mentioned at the end of the ppt here: https://decibel.ni.com/content/message/46314#46314
(note - please check till the end of the thread, as there are several pending modifications that will be posted soon*)
*soon=when I have that mythical thing known as free time...