Pages: 1 2
Am 21.02.2018 um 15:09 schrieb Sönke Ludwig:
(which would be called as
runTask(callback, ...)).
Correction: the callback passed to eventDriver.sockets.waitForData
would of course be called normally by eventcore, but the user supplied
callback would then be called using runTask.
On Wed, 21 Feb 2018 15:25:44 +0100, Sönke Ludwig wrote:
Am 21.02.2018 um 15:09 schrieb Sönke Ludwig:
(which would be called as
runTask(callback, ...)).Correction: the callback passed to
eventDriver.sockets.waitForData
would of course be called normally by eventcore, but the user supplied
callback would then be called usingrunTask.
I have tried to draft an implementation of said method this way:
https://github.com/FraMecca/vibe-core/commit/0d6ba62f513a809906e729a622deb1ba86415328
I have another question concerning the following constraint from the wiki:
layered on top is a (more or less) 0.8.1 compatible high level API, using structs instead of classes to enable a scoped API without requiring all users to add scope to their request handlers
Which class needs to be changed?
I think that porting HTTPServerRequest and HTTPServerResponse to structs requires a change to the rest of the api, in particular the requestHandler provided by the user, to accept references to req and ref thus breaking the compatibility with the previous api.
On Wed, 07 Mar 2018 21:52:04 GMT, FraMecca wrote:
I have another question concerning the following constraint from the wiki:
layered on top is a (more or less) 0.8.1 compatible high level API, using structs instead of classes to enable a scoped API without requiring all users to add scope to their request handlers
Which class needs to be changed?
I think that porting HTTPServerRequest and HTTPServerResponse to structs requires a change to the rest of the api, in particular the requestHandler provided by the user, to accept references to req and ref thus breaking the compatibility with the previous api.
The idea is that the struct is passed by value and contains a pointer to the actual data as a private member. The fields would be represented by properties returning scope data, so that once DIP1000 has made it into mainline, no data can escape the request handler. After some recent discussion, this turned out to be the only viable option to get performance, safety and backwards compatibility together.
struct HTTPServerRequest {
private HTTPServerRequestData* m_data;
@property scope string requestURI() const { return m_data.requestURI; }
}
Thank you,
this is now clear.
On Wed, 07 Mar 2018 22:19:51 GMT, Sönke Ludwig wrote:
On Wed, 07 Mar 2018 21:52:04 GMT, FraMecca wrote:
I have another question concerning the following constraint from the wiki:
layered on top is a (more or less) 0.8.1 compatible high level API, using structs instead of classes to enable a scoped API without requiring all users to add scope to their request handlers
Which class needs to be changed?
I think that porting HTTPServerRequest and HTTPServerResponse to structs requires a change to the rest of the api, in particular the requestHandler provided by the user, to accept references to req and ref thus breaking the compatibility with the previous api.
The idea is that the struct is passed by value and contains a pointer to the actual data as a private member. The fields would be represented by properties returning
scopedata, so that once DIP1000 has made it into mainline, no data can escape the request handler. After [some recent discussion][1], this turned out to be the only viable option to get performance, safety and backwards compatibility together.struct HTTPServerRequest { private HTTPServerRequestData* m_data; @property scope string requestURI() const { return m_data.requestURI; } }[1]: https://github.com/vibe-d/vibe-http/issues/1
Pages: 1 2