OWIN + System.Net.Http + Railways
116 views
Skip to first unread message
Ryan Riley
Jul 21, 2014, 2:19:42 PM7/21/14
to web-st...@googlegroups.com
I just finished my dyfrig branch to combine OWIN compatibility with System.Net.Http types using the railway pattern. I would love feedback.
Ryan Riley
Jul 21, 2014, 10:08:38 PM7/21/14
to web-st...@googlegroups.com, Steffen Forkmann
I feel pretty good about overall design of Dyfrig. I would appreciate feedback.
I'd also like to see if I could start incorporating some things from HyperF into Dyfrig. I'll plan to take a dependency soon. In particular, I'd like to use the stream processing in HyperF. I'm also curious about using other data structures. I've heard Steffen mention some really good performance with Vectors and wonder if that might be a better data structure to use than the mutable Dictionary I'm currently using everywhere. Other suggestions are welcome. Of course, I'm also curious to see if Hopac would be better fit than the Async model.
I also need to start looking into how the recent changes might affect Taliesin, which is currently still OWIN-focused. Hopac is of interest, here, as well.
Next steps summary:
- Take a dependency on HyperF for stream processing
- Figure out how HyperF's filters might work with one of the programming models available in Dyfrig
- Investigate data structures to replace the environment and headers dictionaries
- Investigate use of Hopac
- Investigate impact of recent changes on Taliesin
Thoughts?
Ryan Riley
Jul 22, 2014, 12:10:05 AM7/22/14
to web-st...@googlegroups.com, sfor...@googlemail.com
I'll add https://github.com/nessos/Streams to the list of libraries to investigate. It looks promising.
Vesa Karvonen
Jul 22, 2014, 11:37:47 AM7/22/14
to web-st...@googlegroups.com, sfor...@googlemail.com
Hello,
When/If you do try Hopac, feel free to submit issues and also email me directly. I would also appreciate even short notes on things that you found confusing at first, but then worked out yourself, so I might be able to improve the documentation when I have the time.
My opinion is, of course, very biased, but I'd say that the top reasons to prefer Async over Hopac would be the following:
1) Preservation of synchronization contexts is required throughout your application domain. It is a key design decision made in Hopac to use a custom parallel scheduler for performance reasons and preservation of synchronization contexts is very unlikely to be supported by Hopac.
2) Fully cooperative scheduling is out of the question. This is also another key design decision made in Hopac for performance reasons. It is possible, perhaps even likely, that Hopac will allow for a variety of scheduling options in the future, but there is no guarantee and the current design is cooperative, while Async makes some preemptive switches.
3) You want to use an "official" library from Microsoft or some other company.
4) You already have a significant Async codebase and/or you need to interface with other Async based libraries in performance significant ways.
5) You find that MailboxProcessor or some other particular feature of Async is a better fit to your problem.
As I'm writing this email, I'm adding some basic operations to Hopac to make it easier to interface Async and Hopac code. For example, there will operations to convert Async operations to Hopac jobs and vice versa and you will be able to directly bind Async operations within Hopac jobs, but those conversions, of course, incur some overheads.
Top reasons to prefer Hopac over Async would be better performance and the direct availability of more expressive CML -style concurrent communication mechanisms. You could implement CML -style operations on top of current Async, but performance would likely be worse than Hopac.
As I've mentioned in several places already, before labeling Hopac as version 1.0.0, I plan to do one more pass over the programming interface of Hopac. The main reason being is that I want to investigate whether making more use of computation expressions could make the programming interface more convenient. I also plan to provide a module or namespace that provides as much as possible a drop-in replacement for Async so that in many cases one could then simply open that namespace and recompile to switch to or test with Hopac.
I'm also open to moving Hopac to fsprojects or some other Github organization for collaboration purposes.
-Vesa
When/If you do try Hopac, feel free to submit issues and also email me directly. I would also appreciate even short notes on things that you found confusing at first, but then worked out yourself, so I might be able to improve the documentation when I have the time.
My opinion is, of course, very biased, but I'd say that the top reasons to prefer Async over Hopac would be the following:
1) Preservation of synchronization contexts is required throughout your application domain. It is a key design decision made in Hopac to use a custom parallel scheduler for performance reasons and preservation of synchronization contexts is very unlikely to be supported by Hopac.
2) Fully cooperative scheduling is out of the question. This is also another key design decision made in Hopac for performance reasons. It is possible, perhaps even likely, that Hopac will allow for a variety of scheduling options in the future, but there is no guarantee and the current design is cooperative, while Async makes some preemptive switches.
3) You want to use an "official" library from Microsoft or some other company.
4) You already have a significant Async codebase and/or you need to interface with other Async based libraries in performance significant ways.
5) You find that MailboxProcessor or some other particular feature of Async is a better fit to your problem.
As I'm writing this email, I'm adding some basic operations to Hopac to make it easier to interface Async and Hopac code. For example, there will operations to convert Async operations to Hopac jobs and vice versa and you will be able to directly bind Async operations within Hopac jobs, but those conversions, of course, incur some overheads.
Top reasons to prefer Hopac over Async would be better performance and the direct availability of more expressive CML -style concurrent communication mechanisms. You could implement CML -style operations on top of current Async, but performance would likely be worse than Hopac.
As I've mentioned in several places already, before labeling Hopac as version 1.0.0, I plan to do one more pass over the programming interface of Hopac. The main reason being is that I want to investigate whether making more use of computation expressions could make the programming interface more convenient. I also plan to provide a module or namespace that provides as much as possible a drop-in replacement for Async so that in many cases one could then simply open that namespace and recompile to switch to or test with Hopac.
I'm also open to moving Hopac to fsprojects or some other Github organization for collaboration purposes.
-Vesa
Anton Tayanovskyy
Jul 23, 2014, 8:43:09 PM7/23/14
to web-st...@googlegroups.com
Performance is overrated. I'd like to blog about it sometime. In a
nutshell, use Hopac because it is expressive, not because it is fast
(though that's nice).
There are many things you can do for stream processing, Machines,
Streams, what have you, but they fall between two chairs. If you want
expressive, these things are not expressive enough (compared to
Hopac). If you want fast, eliminating all abstraction by manually
inlining and optimizing critical sections is always going to be
faster, by several orders of magnitude (CLR penalizes abstraction..).
It appears you should always start with from the expressive side, and
optimize only as necessary.
Hopac process networks generalize streams processors - one
input/output or many, buffered or synchronous, static or dynamic
connections. Not only all these things are easy to write, the
vocabulary you need to know is fairly small too - easy to learn.
Thanks,
--A
nutshell, use Hopac because it is expressive, not because it is fast
(though that's nice).
There are many things you can do for stream processing, Machines,
Streams, what have you, but they fall between two chairs. If you want
expressive, these things are not expressive enough (compared to
Hopac). If you want fast, eliminating all abstraction by manually
inlining and optimizing critical sections is always going to be
faster, by several orders of magnitude (CLR penalizes abstraction..).
It appears you should always start with from the expressive side, and
optimize only as necessary.
Hopac process networks generalize streams processors - one
input/output or many, buffered or synchronous, static or dynamic
connections. Not only all these things are easy to write, the
vocabulary you need to know is fairly small too - easy to learn.
Thanks,
--A
Reply all
Reply to author
Forward
0 new messages