Re: [akka-user] Akka-Typed MutableBehavior: return type of onMessage

2017-07-18 Thread Mushtaq Ahmed 
I am not able to understand when to make use of it instead of always 
returning 'this' outside the match block in MutableBehaviour. Sounds 
redundant right now, but maybe I need to write a bit more code to see the 
utility.

On Wednesday, July 19, 2017 at 5:20:19 AM UTC+5:30, Konrad Malawski wrote:
>
> Exactly the same. 
> Becoming an different behavior.
>
> On July 19, 2017 at 0:16:18, Mushtaq Ahmed (mush...@gmail.com 
> ) wrote:
>
>> Actor.immutable returning Behaviour[T] makes sense as it uses recursion 
>> to return updated state or Actor.stopped etc.  
>>
>> But in MutableBehavior, I end up using this pattern a lot.
>>
>> override def onMessage(msg: Msg): Behavior[Msg] = {
>> msg match {
>> case M1 => //unit returning action
>> case M2 => //unit returning action
>> }
>> this
>> }
>>
>>
>> Which makes me wonder what use cases are helped by onMessage returning 
>> Behaviour type (instead of Unit). Any thoughts?
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-Typed MutableBehavior: return type of onMessage

2017-07-18 Thread Konrad “ktoso” Malawski 
Exactly the same.
Becoming an different behavior.

On July 19, 2017 at 0:16:18, Mushtaq Ahmed (mushta...@gmail.com) wrote:

> Actor.immutable returning Behaviour[T] makes sense as it uses recursion to
> return updated state or Actor.stopped etc.
>
> But in MutableBehavior, I end up using this pattern a lot.
>
> override def onMessage(msg: Msg): Behavior[Msg] = {
> msg match {
> case M1 => //unit returning action
> case M2 => //unit returning action
> }
> this
> }
>
>
> Which makes me wonder what use cases are helped by onMessage returning
> Behaviour type (instead of Unit). Any thoughts?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Akka-Typed MutableBehavior: return type of onMessage

2017-07-18 Thread Mushtaq Ahmed 
Actor.immutable returning Behaviour[T] makes sense as it uses recursion to 
return updated state or Actor.stopped etc. 

But in MutableBehavior, I end up using this pattern a lot.

override def onMessage(msg: Msg): Behavior[Msg] = {
msg match {
case M1 => //unit returning action
case M2 => //unit returning action
}
this
}


Which makes me wonder what use cases are helped by onMessage returning 
Behaviour type (instead of Unit). Any thoughts?

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Cannot stop actor running akka stream

2017-07-18 Thread Akka Team 
Hi,

There is nowhere in that shared snippet where you actually use the kill
switch to stop the stream?
A reasonable place to use the kill switch would be the postStop hook of the
actor.
This 3 part series of articles by Colin Breck may help:
http://blog.colinbreck.com/integrating-akka-streams-and-akka-actors-part-i/

--
Johan
Akka Team

On Thu, Jul 6, 2017 at 7:43 PM, Lap Ming Lee  wrote:

> I cannot stop an actor running akka stream even with killswitch.  How do I
> properly stop an actor running an akka stream?
>
> private def startStream(maybeOffset: Option[ProcessedEventOffset]): Unit = {
>   implicit val materializer = ActorMaterializer()
>
>   val publisher = SomePublisher
>
>   val (killSwitch, done) = Source
> .fromPublisher(publisher)
> .viaMat(KillSwitches.single)(Keep.right)
> .toMat(Sink.ignore)(Keep.both)
> .run()
>
>   done.onComplete {
> case Success(_) =>
>   context.stop(self)
>
> case Failure(e) => // receive an error from the stream
>   log.error(e, "Error while processing stream")
>   context.stop(self)
>   }
>
>   maybeSwitch = Some(killSwitch)
> }
>
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Typed API discussion

2017-07-18 Thread Bryan Murphy 
It looks like if you were writing anything that wrapped another Behavior 
you would have code that is like what is in Widened which has to allow for 
Same, Deferred and Unhandled.  

If you look at Immutable as a potential model for wrtiting a simple class 
that extends behavior you see it is final and extends 
BehaviorImpl.ImmutableBehavior which has to contend with two different 
ActorContext types and wonder if you have to do it that way too. 

On Tuesday, 18 July 2017 22:17:57 UTC+10, rkuhn wrote:
>
> There already is ExtensibleBehavior, does that not provide you with all 
> the access and tools you need?
>
> 18 juli 2017 kl. 13:53 skrev Bryan Murphy  >:
>
> I mostly agree with you and the NamedStateBehavior may only be useful when 
> you have well defined state transitions (low change frequency) or not 
> useful at all but the point is it I could write it and decide if it was 
> useful if Behavour supported being extensible.  I can't see how I could do 
> that with the current implementation.  Tomorow I might come up with another 
> idea like having a behaviour that acted as a cache for another behavior or 
> ...
>
> On Tuesday, 18 July 2017 21:40:07 UTC+10, rkuhn wrote:
>>
>> Hi Bryan,
>>
>> thanks for articulating your points! Regarding the first one I’d like to 
>> widen the scope of the discussion: is it useful to access the private state 
>> of a state machine for testing purposes? I know that I am guilty of 
>> creating the akka-testkit nearly seven years ago, allowing precisely that. 
>> My own experience and understanding has evolved since then, and it will 
>> likely continue evolving in the future, so take my learnings with a grain 
>> of salt.
>>
>> My current take on this topic is that tests that access the internal 
>> state of a state machine (or any kind of component) tend to be too closely 
>> coupled to the implementation, to the point of becoming useless. The latter 
>> shows when noticing that every change of the implementation requires a 
>> matching change to the test suite—but what good is a test suite that just 
>> echoes all changes, including the buggy ones? My preference is to formulate 
>> tests on the level of expected and externally observable behavior, this has 
>> a greater chance of remaining constant across feature additions, 
>> refactorings, etc.
>>
>> This is the reason why the focus for Akka Typed tests has been placed on 
>> synchronous evaluation with effect capturing, meaning that responses to 
>> external stimulus can be observed in a deterministic and efficient fashion. 
>> The example of the chat room client list would best be tested by adding 
>> clients and then sending a message, followed by checking that all clients 
>> (“mocked” by using debugging ActorRefs that just collect incoming messages) 
>> received the chatroom communication. This validates a core feature of the 
>> chatroom without depending on assumptions regarding the implementation.
>>
>> Regards,
>>
>> Roland
>>
>> 18 juli 2017 kl. 11:44 skrev Bryan Murphy :
>>
>> OK,  I will start it here.  The main thing is get the comments and ideas 
>> in front of the Akka developers - if it is has merit you can run with it.
>>
>> Overall I like the direction of AkkaTyped but there are a couple of use 
>> cases that I would like to see that seem not supported by the current 
>> implementation (but have become possible with the separation of Behaviour 
>> and Actor).
>>
>>
>>1. Behaviours are like state machines so when testing I would like to 
>>send a message to the behaviour and then verify the resultant behaviour 
>> is 
>>what I expect.  Ideally a behaviour would have a name (or an identifier 
>>with a  generic Identifier type if we want to be more general) and some 
>>state data that we could look at (eg often we keep the same behavior but 
>>the internal state data has been updated eg sessions in the Chat Room 
>>example).  The current approach makes the state data opaque because the 
>>state become parameters to a function that creates the behavior so the 
>>state is hidden in the closure.  In fact the whole Behaviour is opaque 
>> (you 
>>can only make behaviors using the provided factory functions because the 
>>interpretation of behaviors has leaked into every Behavior implementation 
>>so it would be unsafe for users to create their own Behaviors) making it 
>>impossible to extend Behavior to add a name or add State data.  For name 
>> we 
>>could perhaps override toString but that feels like a hack.
>>
>>
>>
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving

Re: [akka-user] Akka Typed API discussion

2017-07-18 Thread Roland Kuhn 
There already is ExtensibleBehavior, does that not provide you with all the 
access and tools you need?

> 18 juli 2017 kl. 13:53 skrev Bryan Murphy :
> 
> I mostly agree with you and the NamedStateBehavior may only be useful when 
> you have well defined state transitions (low change frequency) or not useful 
> at all but the point is it I could write it and decide if it was useful if 
> Behavour supported being extensible.  I can't see how I could do that with 
> the current implementation.  Tomorow I might come up with another idea like 
> having a behaviour that acted as a cache for another behavior or ...
> 
> On Tuesday, 18 July 2017 21:40:07 UTC+10, rkuhn wrote:
> Hi Bryan,
> 
> thanks for articulating your points! Regarding the first one I’d like to 
> widen the scope of the discussion: is it useful to access the private state 
> of a state machine for testing purposes? I know that I am guilty of creating 
> the akka-testkit nearly seven years ago, allowing precisely that. My own 
> experience and understanding has evolved since then, and it will likely 
> continue evolving in the future, so take my learnings with a grain of salt.
> 
> My current take on this topic is that tests that access the internal state of 
> a state machine (or any kind of component) tend to be too closely coupled to 
> the implementation, to the point of becoming useless. The latter shows when 
> noticing that every change of the implementation requires a matching change 
> to the test suite—but what good is a test suite that just echoes all changes, 
> including the buggy ones? My preference is to formulate tests on the level of 
> expected and externally observable behavior, this has a greater chance of 
> remaining constant across feature additions, refactorings, etc.
> 
> This is the reason why the focus for Akka Typed tests has been placed on 
> synchronous evaluation with effect capturing, meaning that responses to 
> external stimulus can be observed in a deterministic and efficient fashion. 
> The example of the chat room client list would best be tested by adding 
> clients and then sending a message, followed by checking that all clients 
> (“mocked” by using debugging ActorRefs that just collect incoming messages) 
> received the chatroom communication. This validates a core feature of the 
> chatroom without depending on assumptions regarding the implementation.
> 
> Regards,
> 
> Roland
> 
>> 18 juli 2017 kl. 11:44 skrev Bryan Murphy murphynet.id.au 
>> >:
>> 
>> OK,  I will start it here.  The main thing is get the comments and ideas in 
>> front of the Akka developers - if it is has merit you can run with it.
>> 
>> Overall I like the direction of AkkaTyped but there are a couple of use 
>> cases that I would like to see that seem not supported by the current 
>> implementation (but have become possible with the separation of Behaviour 
>> and Actor).
>> 
>> Behaviours are like state machines so when testing I would like to send a 
>> message to the behaviour and then verify the resultant behaviour is what I 
>> expect.  Ideally a behaviour would have a name (or an identifier with a  
>> generic Identifier type if we want to be more general) and some state data 
>> that we could look at (eg often we keep the same behavior but the internal 
>> state data has been updated eg sessions in the Chat Room example).  The 
>> current approach makes the state data opaque because the state become 
>> parameters to a function that creates the behavior so the state is hidden in 
>> the closure.  In fact the whole Behaviour is opaque (you can only make 
>> behaviors using the provided factory functions because the interpretation of 
>> behaviors has leaked into every Behavior implementation so it would be 
>> unsafe for users to create their own Behaviors) making it impossible to 
>> extend Behavior to add a name or add State data.  For name we could perhaps 
>> override toString but that feels like a hack.
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
>

Re: [akka-user] Akka Typed API discussion

2017-07-18 Thread Bryan Murphy 

I mostly agree with you and the NamedStateBehavior may only be useful when 
you have well defined state transitions (low change frequency) or not 
useful at all but the point is it I could write it and decide if it was 
useful if Behavour supported being extensible.  I can't see how I could do 
that with the current implementation.  Tomorow I might come up with another 
idea like having a behaviour that acted as a cache for another behavior or 
...

On Tuesday, 18 July 2017 21:40:07 UTC+10, rkuhn wrote:
>
> Hi Bryan,
>
> thanks for articulating your points! Regarding the first one I’d like to 
> widen the scope of the discussion: is it useful to access the private state 
> of a state machine for testing purposes? I know that I am guilty of 
> creating the akka-testkit nearly seven years ago, allowing precisely that. 
> My own experience and understanding has evolved since then, and it will 
> likely continue evolving in the future, so take my learnings with a grain 
> of salt.
>
> My current take on this topic is that tests that access the internal state 
> of a state machine (or any kind of component) tend to be too closely 
> coupled to the implementation, to the point of becoming useless. The latter 
> shows when noticing that every change of the implementation requires a 
> matching change to the test suite—but what good is a test suite that just 
> echoes all changes, including the buggy ones? My preference is to formulate 
> tests on the level of expected and externally observable behavior, this has 
> a greater chance of remaining constant across feature additions, 
> refactorings, etc.
>
> This is the reason why the focus for Akka Typed tests has been placed on 
> synchronous evaluation with effect capturing, meaning that responses to 
> external stimulus can be observed in a deterministic and efficient fashion. 
> The example of the chat room client list would best be tested by adding 
> clients and then sending a message, followed by checking that all clients 
> (“mocked” by using debugging ActorRefs that just collect incoming messages) 
> received the chatroom communication. This validates a core feature of the 
> chatroom without depending on assumptions regarding the implementation.
>
> Regards,
>
> Roland
>
> 18 juli 2017 kl. 11:44 skrev Bryan Murphy  >:
>
> OK,  I will start it here.  The main thing is get the comments and ideas 
> in front of the Akka developers - if it is has merit you can run with it.
>
> Overall I like the direction of AkkaTyped but there are a couple of use 
> cases that I would like to see that seem not supported by the current 
> implementation (but have become possible with the separation of Behaviour 
> and Actor).
>
>
>1. Behaviours are like state machines so when testing I would like to 
>send a message to the behaviour and then verify the resultant behaviour is 
>what I expect.  Ideally a behaviour would have a name (or an identifier 
>with a  generic Identifier type if we want to be more general) and some 
>state data that we could look at (eg often we keep the same behavior but 
>the internal state data has been updated eg sessions in the Chat Room 
>example).  The current approach makes the state data opaque because the 
>state become parameters to a function that creates the behavior so the 
>state is hidden in the closure.  In fact the whole Behaviour is opaque 
> (you 
>can only make behaviors using the provided factory functions because the 
>interpretation of behaviors has leaked into every Behavior implementation 
>so it would be unsafe for users to create their own Behaviors) making it 
>impossible to extend Behavior to add a name or add State data.  For name 
> we 
>could perhaps override toString but that feels like a hack.
>
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Typed API discussion

2017-07-18 Thread Roland Kuhn 
Hi Bryan,

thanks for articulating your points! Regarding the first one I’d like to widen 
the scope of the discussion: is it useful to access the private state of a 
state machine for testing purposes? I know that I am guilty of creating the 
akka-testkit nearly seven years ago, allowing precisely that. My own experience 
and understanding has evolved since then, and it will likely continue evolving 
in the future, so take my learnings with a grain of salt.

My current take on this topic is that tests that access the internal state of a 
state machine (or any kind of component) tend to be too closely coupled to the 
implementation, to the point of becoming useless. The latter shows when 
noticing that every change of the implementation requires a matching change to 
the test suite—but what good is a test suite that just echoes all changes, 
including the buggy ones? My preference is to formulate tests on the level of 
expected and externally observable behavior, this has a greater chance of 
remaining constant across feature additions, refactorings, etc.

This is the reason why the focus for Akka Typed tests has been placed on 
synchronous evaluation with effect capturing, meaning that responses to 
external stimulus can be observed in a deterministic and efficient fashion. The 
example of the chat room client list would best be tested by adding clients and 
then sending a message, followed by checking that all clients (“mocked” by 
using debugging ActorRefs that just collect incoming messages) received the 
chatroom communication. This validates a core feature of the chatroom without 
depending on assumptions regarding the implementation.

Regards,

Roland

> 18 juli 2017 kl. 11:44 skrev Bryan Murphy :
> 
> OK,  I will start it here.  The main thing is get the comments and ideas in 
> front of the Akka developers - if it is has merit you can run with it.
> 
> Overall I like the direction of AkkaTyped but there are a couple of use cases 
> that I would like to see that seem not supported by the current 
> implementation (but have become possible with the separation of Behaviour and 
> Actor).
> 
> Behaviours are like state machines so when testing I would like to send a 
> message to the behaviour and then verify the resultant behaviour is what I 
> expect.  Ideally a behaviour would have a name (or an identifier with a  
> generic Identifier type if we want to be more general) and some state data 
> that we could look at (eg often we keep the same behavior but the internal 
> state data has been updated eg sessions in the Chat Room example).  The 
> current approach makes the state data opaque because the state become 
> parameters to a function that creates the behavior so the state is hidden in 
> the closure.  In fact the whole Behaviour is opaque (you can only make 
> behaviors using the provided factory functions because the interpretation of 
> behaviors has leaked into every Behavior implementation so it would be unsafe 
> for users to create their own Behaviors) making it impossible to extend 
> Behavior to add a name or add State data.  For name we could perhaps override 
> toString but that feels like a hack.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Typed API discussion

2017-07-18 Thread Konrad “ktoso” Malawski 
Hi Bryan,
The forum differs a bit depending on what you want to chat about.

Do you have a few issues to talk about and they’re specific enough (and
potentially could have an actionable outcome I’d assume/hope)? Then
http://github.com/akka/akka would be the best, one ticket per specific
issue, not to get all into the same one :)

We also have http://github.com/akka/akka-meta for more abstract
discussions, ideological etc ;-)

Or here is also find, if it’s one specific thing that you think requires a
lot more discussion before it can be formulated into an more or less
actionable ticket.

Hope this helps.

I’d suggest to keep it here or on issues, from what it sounds; chat is not
as good for deeply pondering an API and well thought out debate, emails or
issues work there a bit better :)

Thanks!

—
Konrad `kto.so` Malawski
Akka  @ Lightbend 

On 18 July 2017 at 15:59:11, Bryan Murphy (br...@murphynet.id.au) wrote:

Where is the best place to discuss the Akka Typed API ?
I am hoping it is still open to change as I have some (reasonably lengthy)
comments and suggestions to make so I want to make sure I give them in the
correct forum.
Is it here, a gitter channel, a github issue or somewhere else ?

Thanks

Bryan
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
"Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Akka Typed API discussion

2017-07-18 Thread Bryan Murphy 
Where is the best place to discuss the Akka Typed API ?
I am hoping it is still open to change as I have some (reasonably lengthy) 
comments and suggestions to make so I want to make sure I give them in the 
correct forum.
Is it here, a gitter channel, a github issue or somewhere else ?

Thanks

Bryan

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.