Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement FBP protocol endpoint #14

Open
bergie opened this issue Jan 19, 2016 · 5 comments
Open

Implement FBP protocol endpoint #14

bergie opened this issue Jan 19, 2016 · 5 comments

Comments

@bergie
Copy link
Collaborator

bergie commented Jan 19, 2016

It would be nice to make PhpFlo a Flowhub compatible FBP runtime by implementing the FBP protocol. In addition to Flowhub, this would also open the possibility to use other FBP tooling like fbp-spec and flowtrace.

One option is via Ratchet: http://socketo.me/docs/hello-world

@maschmann
Copy link
Contributor

I'd suggest to implement FBP protocol as a separate library which in turn could be used as a dependency for this one. In my opinion the protocol would be too much implementation detail for this lib.
Also it would be more open for integration into other tools.

@aretecode
Copy link
Collaborator

@maschmann in noflo we do have fbp and fbp-protocol dependencies. https://github.com/noflo/noflo/blob/master/package.json#L18

@maschmann
Copy link
Contributor

@aretecode first of all: Thank you for reviewing, the good feedback and merging 👍

BTT: I am not sure how to integrate the endpoint for FBP protocol :-)

Some other questions also bother me for some time now: Is async for those processes (php context) the correct approach since most php programming is done in the synchronous way. Background for this concern is my current work with data import and transformation. If you have a workflow where you build a dataset from different sources through several processes and use dependencies for those processes (what the bundle allows), you have the Framework or whatever else you use with phpflo always boot up for every process, including DIC build, etc. which considerably decreases performance and also logistics due to missing shared state of the framework. Communication between threads/processes is also really difficult to master in that scenario. In a standalone scenario (only phpflo & some components) it should be easy enough: But how often is this the case?
Maybe this is easy to solve - but as of now I don't see a useful solution.

btw: Flowtrace would be a really nice-to-have feature. Have spent a few hours figuring out how the logging format should look like and where to catch the communication between the processes.

@aretecode
Copy link
Collaborator

aretecode commented Jul 24, 2016

@maschmann

Good points and questions! :-)

Async

Asynchronous is not necessary in PHP. It makes things more complex to manage.

State

There are plenty of ways to share the state, in some noflo repos we use something similar to a Registry. You could pass in whatever part of the framework in a port and update it.

Performance

Loading everything without long running processes, the startup time is not optimal, and in PHP it is difficult to improve drastically. Benefits vs negatives right.

Flowtrace

Wouldn't you be able to listen to the event emitting from the sockets?

P.S...

Process API

https://github.com/noflo/noflo/blob/master/src/lib/Component.coffee#L93
Is really nice to use in noflo.

FBP

The other option is using https://github.com/flowbased/fbp to convert FBP to JSON so people can still write FBP.

Did that answer most of it or did I miss anything?

@maschmann
Copy link
Contributor

@aretecode thanks for the time and the explanation :-)

To summarize the next steps:

  • Async not at first, because of unnecessary complexity
  • Since async is not an issue, state is solved (for now)
  • ... as is performance
  • trace: will have an endpoint in the InternalSocket
  • I'll check on the current component implementation for the process API

If I have more questions, I'll bother you again :-)

@qooco qooco mentioned this issue Jan 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants