CloudState/community

Viktor Klang (√)

@viktorklang

@marcellanz There are no expected replies for Init and Event though (IIRC)

Marcel Lanz

@marcellanz

I see. I set command_id to 0 (where an entity is already "Inited") and the proxy told me there is an error for a unspecific error unrelated/unkown command.

Then if a Init fails, and does not report back a Failure, the next command would be replied by a Failure I guess; as there would not be an entity with the expected entity-id of the command.

János Szathmáry

@janory

@marcellanz My two cents: Either there is no EntityHandler yet when Init comes, in this case you should create an EntityHandler (this should not fail), or there is already one EntityHandler in place when Init comes, this case you should report back a Failure with "Init message received twice." If the implementation for whatever reason fails to create an EntityHandler on Init, as you have already stated the next command should fail with "Event received before init"

Marcel Lanz

@marcellanz

@janory for this is also what I understand. For "this case you should report back a Failure with "Init message received twice." there is no command_id to be set in this case as there is no command and in this case, regarding the spec, its not clear what to set for command_id in Failure.

(sorry to be picky :-) )

Akram Ahmad

@akramtexas

Please keep these conversations going :thumbsup: - I'm (re)learning a thing or two as I closely follow the exchanges on the goodness of EntityHandlers and stuff like that (and how they're done in CloudState)

Marcel Lanz

@marcellanz

@janory ... I might not send a command_id in Failure in this case

János Szathmáry

@janory

@marcellanz No problem :) The proxy logic might have been changed since I was playing around with this in Scala, but here is my very dirty (and definitely not finished) implementation on it: https://github.com/janory/cloudstate/blob/add_scala_support_for_user_functions/scala-support/src/main/scala/io/cloudstate/scala/support/EventSourcedServiceImpl.scala#L39

When I did it, it was not necessary to set the command_id

@janory ... I might not send a command_id in Failure in this case

@marcellanz Yes this is what I weanted to say, it's not mandatory

Marcel Lanz

@marcellanz

@janory perfect. The current proxy implementation even reports that it got a Failure that is unrelated to a command; I just was not sure about this. Maybe it can be stated in the spec.

Andy Czerwonka

@andyczerwonka

@janory what timezone are you in?

János Szathmáry

@janory

@janory what timezone are you in?

GMT+2

Andy Czerwonka

@andyczerwonka

uhggg... GMT-7 :-(

I seem to be the outlier here in Western Canada

János Szathmáry

@janory

@janory perfect. The current proxy implementation even reports that it got a Failure that is unrelated to a command; I just was not sure about this. Maybe it can be stated in the spec.

@marcellanz Yes it's a non command specific error: https://github.com/janory/cloudstate/blob/add_scala_support_for_user_functions/proxy/core/src/main/scala/io/cloudstate/proxy/eventsourced/EventSourcedEntity.scala#L261

János Szathmáry

@janory

uhggg... GMT-7 :-(
I seem to be the outlier here in Western Canada

@andyczerwonka ahhh :( that's almost the worst possible combination :D

Andy Czerwonka

@andyczerwonka

yep

we have a call next week

János Szathmáry

@janory

@andyczerwonka okay... https://www.timeanddate.com/worldclock/converter.html?iso=20190911T170000&p1=3921&p2=3904 this is actually acceptable from both sides

Akram Ahmad

@akramtexas

Weekly call details :arrow_heading_up:

Andy Czerwonka

@andyczerwonka

yes, you can add it to your calendar, commit for the link was yesterday

János Szathmáry

@janory

@andyczerwonka yeah, I've seen this already

Akram Ahmad

@akramtexas

:cool:

János Szathmáry

@janory

@akramtexas thanks! :)

Akram Ahmad

@akramtexas

@janory for sure, anytime! :smiley:

Marcel Lanz

@marcellanz

@janory thanks. I see this is a Scala Client API implementation of yours; I see (obviously as we implement the same spec) many familiar things :-)

Viktor Klang (√)

@viktorklang

We're going to want to start a formalization of the protocol specification rather soon. The reason we waited to do that was to be able to both experiment with expressing different storage models, as well as getting more external collaborators before setting it "in stone" :)

Akram Ahmad

@akramtexas

:dart: :thumbsup:

Kevin O'Neill

@kevinoneill

Hey all. Firstly I’m interested in working on an adaptors for Swift. Is there some sort of validation Entity that can be used to verify implementations so i can get a clearer idea of what’s required?

Kevin O'Neill

@kevinoneill

Ahh, the TCK.

Marcel Lanz

@marcellanz

Hi, yes the TCK it is. You can "wire" the tck⁩/⁨src⁩/⁨it⁩/⁨resources⁩/application.conf to your implementation and then run the TCK

by running sbt tck/it:testlike documented here https://cloudstate.io/docs/developer/language-support/index.html

Viktor Klang (√)

@viktorklang

Hi @kevinoneill, Swift support sounds excellent. Let us know when/if you need any input or have any questions!

Kevin O'Neill

@kevinoneill

I’m sure I will.

Viktor Klang (√)

@viktorklang

@kevinoneill Awesome—my recommendation is to start with the API that the users will use. You can look at how the idiomatic APIs for JS and Java look like first. The idea is to make sure that every platform has an API which makes sense for developers using that language. Then using that API to implement the Shopping Cart protocol, see java-shopping-cart and js-shopping-cart in the samples directory for inspiration. Then when you've arrived at an API which makes sense for Swift, then start implementing a library which defines that API, and then start implementing the cloudstate protocol in that library. Then you can hook up your swift shopping cart example to the TCK to get some assistance in expected semantics.

Kevin O'Neill

@kevinoneill

I’ve been reading the comments on the go ticket which has helped a lot

Viktor Klang (√)

@viktorklang

:+1:

Marcel Lanz

@marcellanz

The TCKs running in IntelliJ gives a nice comparison how an implementation performs... not that I take it seriously, but gives a fuzzy warm feeling.

Akram Ahmad

@akramtexas

:cool:

Marcel Lanz

@marcellanz

I consider to have a docker container compiling the binary for the TCK of the go-support. Can I assume that a cloudstate project developer has docker installed so he can run the TCK without installing something like the go compiler (not that it would be too hard to install that). Has anyone preferences?

Marcel Lanz

@marcellanz

I think I need some help with SBT
I'd like to run a command running/managed by build.sbt

I wish to start a command line by sbt during its build of the tck; or running the tck

docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp -e GOOS=windows -e GOARCH=386 golang:1.13 ./build/build_tck_shopping_cart_in_docker.sh

where the environment variables GOOS/GOARCH might be passed or determined by the current environment.
(combinations of linux/amd64 windows/amd64 and darwin/amd64 might be the most used variation I think)

Marcel Lanz

@marcellanz

… has someone any tipps/hints how to start doing that with SBT?

Marcel Lanz

@marcellanz

lazy val buildGoTCKShoppingCart = taskKey[Unit]("build go-shopping-cart for the TCK") buildGoTCKShoppingCart := { "build/run_tck_shopping_cart_build.sh" ! }

I'm guilty of using Stackoverflow now, and some SBT documentation

Marcel Lanz

@marcellanz

This message was deleted

Marcel Lanz

@marcellanz

… which did not work until I added
import scala.sys.process._

Marcel Lanz

@marcellanz

so I wrote my first scala code since about 2008 or so for a SBT taskin build.sbt.
It works, but I'm pretty sure someone has to have a look at it :-)

Where communities thrive

People

Repo info

Activity