.net 4.5...

[Luke Pulverenti]

Do you plan on supporting some of the new stuff, such as a portable version of ServiceStack.Text, and also async versions of the serialization methods?

[Demis Bellot]

What do you mean? ServiceStack.Text is portable and there are already lots of different builds of it for the most popular platforms.

It also writes to a stream, doesn't use threads and doesn't block, why does it need an async Api?

D.B
Sent from my iPad

[Oskar Karlsson]

Surely you can squeeze in a async Dump or two!

:)

O 

[Luke Pulverenti]

Is it actually a "portable class library" as defined by .net 4.5?

Also in .net 4.0 there are a number of new methods on streams that are async versions of the originals, such as WriteAsync.

[Demis Bellot]

We're not going to implement "portable class libraries" - they don't work in practice, custom builds do - which we already ship in ServiceStack.Text NuGet package.

And what should WriteAsync do? Return immediately after spawning a new thread, than when finished, execute the async/future callback? 

Why exactly would we want the overhead of a spawning a new thread on a non-blocking library?

Which APIs/methods do you think should be async?

--
- Demis

http://twitter.com/demisbellot

http://www.servicestack.net/mythz_blog

[Luke Pulverenti]

The portable class library in .net 4.5 is a brand new thing so I'm not sure why you'd discredit it immediately without first taking a look at it.

I think I read on your website that your code has no external dependencies, which means it probably will compile as a portable project.

On Sunday, July 15, 2012 5:36:56 PM UTC-4, Luke Pulverenti wrote:

[Demis Bellot]

I should've added we're not against adding "portable class libraries" support. 

Devs think its a pancea and works like magic, and we've already received feedback from someone who has attempted it but failed to get them to work, so they went back to using a custom build.

So we're open to taking pull-requests if someone else wants to add support portable class libraries builds - I'm just personally not going to spend the effort myself to do it.

I think I read on your website that your code has no external dependencies, which means it probably will compile as a portable project.

Right, it doesn't have any external deps and would likely make a good candidate.

[Luke Pulverenti]

Also, as far as the async stuff goes, I don't think we really need to get into a performance debate here. This is really a feature request for you to support some of the new api's on streams, and then let us decide what fits our needs in our own implementations.

On Sunday, July 15, 2012 5:36:56 PM UTC-4, Luke Pulverenti wrote:

[Demis Bellot]

We care about performance, except we only pursue it when it makes sense and actually improves performance.

I'm saying async just adds overhead and does NOT improve performance on non blocking Apis. The only way you can return immediately is to spawn a new thread, this always reduces performance on CPU intensive tasks that don't block.

D.B

Sent from my iPad

[Luke Pulverenti]

Yes I know, it's not that important. I just thought I'd mention the new async/await/Task api.

Going portable would really be nice though, because it would allow my consuming class library to become portable as well. 

On Sunday, July 15, 2012 5:36:56 PM UTC-4, Luke Pulverenti wrote:

[Demis Bellot]

Yes we know about Task/async and currently make use of it for our async pipieline, viewable in the async branch of ServiceStack (the web framework) which will be available on our next major release.

Cool well like most things in OSS, whoever needs it first should add it :)

D.B

Sent from my iPad