I am part way through a rough port of ServiceStack to work with .NET APIs for Metro style apps.
Firstly, has there already been some effort put towards this that I have missed?
Secondly, I have never contributed to a GitHub project before. What is the best way to approach it? I imagine I will want some review/discussion before merging anything. Do I do a Fork and then speak to one of the core team re merging?
I'm not aware of any current effort to add support for Metro. There was
some mention of someone attempting it a long time ago, but I've never heard
back from them so I don't expect that effort still exists.
For contributing to GitHub, you basically just want to fork the repository
you want to work on.
Add your changes on your own fork, and then when the changes have been
tested and are ready for merging, just issue a pull-request:
Basically if you want to do any disruptive changes or are unsure whether a
feature should be added to the main project, you should consult this list.
Most new features should ideally be added via
plugins<https://github.com/ServiceStack/ServiceStack/wiki/Plugins>
.
If you want to add support for a different platform, then we just use
#define build symbols, there's plenty of examples in the ServiceStack.Text
and ServiceStack.Common code-bases. Basically each new platform should take
a copy of the project file in its own directory, and the VS.NET project
should include the build symbol for your platform, see the different
platforms in ServiceStack.Text as an example:
https://github.com/ServiceStack/ServiceStack.Text/tree/master/src
Only the client libraries (e.g. ServiceStack.Text + ServiceStack.Common)
are needed in order to call ServiceStack services.
Thanks,
On Sun, Oct 28, 2012 at 11:15 PM, David Churchland
<david.churchl...@hp.com>wrote:
> I am part way through a rough port of ServiceStack to work with .NET APIs
> for Metro style apps.
> Firstly, has there already been some effort put towards this that I have
> missed?
> Secondly, I have never contributed to a GitHub project before. What is
> the best way to approach it? I imagine I will want some review/discussion
> before merging anything. Do I do a Fork and then speak to one of the core
> team re merging?
I have followed just the approach you suggest, using Monotouch etc as a guide.
Unfortunately I don't think much can be done using plugins as the .Net Reflection classes have changed, for example there are many places where Type.GetTypeInfo() is required, for example type.GetTypeInfo().IsEnum rather than type.IsEnum.
I will play with it and dro pyou a note if I need clarification on anything in particular.
On Monday, 29 October 2012 15:57:40 UTC+11, mythz wrote:
> Hi David,
> I'm not aware of any current effort to add support for Metro. There was > some mention of someone attempting it a long time ago, but I've never heard > back from them so I don't expect that effort still exists.
> For contributing to GitHub, you basically just want to fork the repository > you want to work on. > Add your changes on your own fork, and then when the changes have been > tested and are ready for merging, just issue a pull-request:
> Basically if you want to do any disruptive changes or are unsure whether a > feature should be added to the main project, you should consult this list. > Most new features should ideally be added via plugins<https://github.com/ServiceStack/ServiceStack/wiki/Plugins> > .
> If you want to add support for a different platform, then we just use > #define build symbols, there's plenty of examples in the ServiceStack.Text > and ServiceStack.Common code-bases. Basically each new platform should take > a copy of the project file in its own directory, and the VS.NET project > should include the build symbol for your platform, see the different > platforms in ServiceStack.Text as an example: > https://github.com/ServiceStack/ServiceStack.Text/tree/master/src
> Only the client libraries (e.g. ServiceStack.Text + ServiceStack.Common) > are needed in order to call ServiceStack services.
> Thanks,
> On Sun, Oct 28, 2012 at 11:15 PM, David Churchland <david.ch...@hp.com<javascript:> > > wrote:
>> I am part way through a rough port of ServiceStack to work with .NET >> APIs for Metro style apps.
>> Firstly, has there already been some effort put towards this that I have >> missed?
>> Secondly, I have never contributed to a GitHub project before. What is >> the best way to approach it? I imagine I will want some review/discussion >> before merging anything. Do I do a Fork and then speak to one of the core >> team re merging?
On Monday, October 29, 2012 6:14:37 PM UTC+13, David Churchland wrote:
> I have followed just the approach you suggest, using Monotouch etc as a > guide.
> Unfortunately I don't think much can be done using plugins as the .Net > Reflection classes have changed, for example there are many places where > Type.GetTypeInfo() is required, for example type.GetTypeInfo().IsEnum > rather than type.IsEnum.
> I will play with it and dro pyou a note if I need clarification on > anything in particular.
> On Monday, 29 October 2012 15:57:40 UTC+11, mythz wrote:
>> Hi David,
>> I'm not aware of any current effort to add support for Metro. There was >> some mention of someone attempting it a long time ago, but I've never heard >> back from them so I don't expect that effort still exists.
>> For contributing to GitHub, you basically just want to fork the >> repository you want to work on. >> Add your changes on your own fork, and then when the changes have been >> tested and are ready for merging, just issue a pull-request:
>> Basically if you want to do any disruptive changes or are unsure whether >> a feature should be added to the main project, you should consult this >> list. Most new features should ideally be added via plugins<https://github.com/ServiceStack/ServiceStack/wiki/Plugins> >> .
>> If you want to add support for a different platform, then we just use >> #define build symbols, there's plenty of examples in the ServiceStack.Text >> and ServiceStack.Common code-bases. Basically each new platform should take >> a copy of the project file in its own directory, and the VS.NET project >> should include the build symbol for your platform, see the different >> platforms in ServiceStack.Text as an example: >> https://github.com/ServiceStack/ServiceStack.Text/tree/master/src
>> Only the client libraries (e.g. ServiceStack.Text + ServiceStack.Common) >> are needed in order to call ServiceStack services.
>> Thanks,
>> On Sun, Oct 28, 2012 at 11:15 PM, David Churchland <david.ch...@hp.com>wrote:
>>> I am part way through a rough port of ServiceStack to work with .NET >>> APIs for Metro style apps.
>>> Firstly, has there already been some effort put towards this that I >>> have missed?
>>> Secondly, I have never contributed to a GitHub project before. What is >>> the best way to approach it? I imagine I will want some review/discussion >>> before merging anything. Do I do a Fork and then speak to one of the core >>> team re merging?
The use scenario for Metro (or more accurately Windows Store App) is so that I can consume a service stack service using the servicestack client from a Windows Store App. The Windows Store .Net framework is a much reduced version of the .Net 4.5 framework.
Am I being dense? I assumed this would be just as obvious a use case as MonoTouch? Is there some reason I have missed that there seems to be relatively little interest in this?
On Tuesday, 6 November 2012 08:00:33 UTC+11, Mikkel Fishman wrote:
> Perhaps I'm dense, but what is the use scenario for having support for > metro? I'm planning on making a metro app soon so may be able to contribute.
> On Monday, October 29, 2012 6:14:37 PM UTC+13, David Churchland wrote:
>> I have followed just the approach you suggest, using Monotouch etc as a >> guide.
>> Unfortunately I don't think much can be done using plugins as the .Net >> Reflection classes have changed, for example there are many places where >> Type.GetTypeInfo() is required, for example type.GetTypeInfo().IsEnum >> rather than type.IsEnum.
>> I will play with it and dro pyou a note if I need clarification on >> anything in particular.
>> On Monday, 29 October 2012 15:57:40 UTC+11, mythz wrote:
>>> Hi David,
>>> I'm not aware of any current effort to add support for Metro. There was >>> some mention of someone attempting it a long time ago, but I've never heard >>> back from them so I don't expect that effort still exists.
>>> For contributing to GitHub, you basically just want to fork the >>> repository you want to work on. >>> Add your changes on your own fork, and then when the changes have been >>> tested and are ready for merging, just issue a pull-request:
>>> Basically if you want to do any disruptive changes or are unsure whether >>> a feature should be added to the main project, you should consult this >>> list. Most new features should ideally be added via plugins<https://github.com/ServiceStack/ServiceStack/wiki/Plugins> >>> .
>>> If you want to add support for a different platform, then we just use >>> #define build symbols, there's plenty of examples in the ServiceStack.Text >>> and ServiceStack.Common code-bases. Basically each new platform should take >>> a copy of the project file in its own directory, and the VS.NET project >>> should include the build symbol for your platform, see the different >>> platforms in ServiceStack.Text as an example: >>> https://github.com/ServiceStack/ServiceStack.Text/tree/master/src
>>> Only the client libraries (e.g. ServiceStack.Text + ServiceStack.Common) >>> are needed in order to call ServiceStack services.
>>> Thanks,
>>> On Sun, Oct 28, 2012 at 11:15 PM, David Churchland <david.ch...@hp.com>wrote:
>>>> I am part way through a rough port of ServiceStack to work with .NET >>>> APIs for Metro style apps.
>>>> Firstly, has there already been some effort put towards this that I >>>> have missed?
>>>> Secondly, I have never contributed to a GitHub project before. What is >>>> the best way to approach it? I imagine I will want some review/discussion >>>> before merging anything. Do I do a Fork and then speak to one of the core >>>> team re merging?
Most of the support for the different platforms have been contributed to by
the community of different platforms wanting to see support for it.
So far there have been little interest to add support Windows 8, I think
@gshackles is having a go at supporting it, although I'm not sure how far
he's got.
On Tue, Nov 13, 2012 at 5:27 PM, David Churchland
<david.churchl...@hp.com>wrote:
> The use scenario for Metro (or more accurately Windows Store App) is so
> that I can consume a service stack service using the servicestack client
> from a Windows Store App. The Windows Store .Net framework is a much
> reduced version of the .Net 4.5 framework.
> Am I being dense? I assumed this would be just as obvious a use case as
> MonoTouch? Is there some reason I have missed that there seems to be
> relatively little interest in this?
> On Tuesday, 6 November 2012 08:00:33 UTC+11, Mikkel Fishman wrote:
>> Perhaps I'm dense, but what is the use scenario for having support for
>> metro? I'm planning on making a metro app soon so may be able to contribute.
>> On Monday, October 29, 2012 6:14:37 PM UTC+13, David Churchland wrote:
>>> I have followed just the approach you suggest, using Monotouch etc as a
>>> guide.
>>> Unfortunately I don't think much can be done using plugins as the .Net
>>> Reflection classes have changed, for example there are many places where
>>> Type.GetTypeInfo() is required, for example type.GetTypeInfo().**IsEnum
>>> rather than type.IsEnum.
>>> I will play with it and dro pyou a note if I need clarification on
>>> anything in particular.
>>> On Monday, 29 October 2012 15:57:40 UTC+11, mythz wrote:
>>>> Hi David,
>>>> I'm not aware of any current effort to add support for Metro. There was
>>>> some mention of someone attempting it a long time ago, but I've never heard
>>>> back from them so I don't expect that effort still exists.
>>>> For contributing to GitHub, you basically just want to fork the
>>>> repository you want to work on.
>>>> Add your changes on your own fork, and then when the changes have been
>>>> tested and are ready for merging, just issue a pull-request:
>>>> Basically if you want to do any disruptive changes or are unsure
>>>> whether a feature should be added to the main project, you should consult
>>>> this list. Most new features should ideally be added via plugins<https://github.com/ServiceStack/ServiceStack/wiki/Plugins>
>>>> .
>>>> If you want to add support for a different platform, then we just use
>>>> #define build symbols, there's plenty of examples in the ServiceStack.Text
>>>> and ServiceStack.Common code-bases. Basically each new platform should take
>>>> a copy of the project file in its own directory, and the VS.NETproject should include the build symbol for your platform, see the
>>>> different platforms in ServiceStack.Text as an example:
>>>> https://github.com/**ServiceStack/ServiceStack.**Text/tree/master/src<https://github.com/ServiceStack/ServiceStack.Text/tree/master/src>
>>>> Only the client libraries (e.g. ServiceStack.Text +
>>>> ServiceStack.Common) are needed in order to call ServiceStack services.
>>>> Thanks,
>>>> On Sun, Oct 28, 2012 at 11:15 PM, David Churchland <david.ch...@hp.com>wrote:
>>>>> I am part way through a rough port of ServiceStack to work with .NET
>>>>> APIs for Metro style apps.
>>>>> Firstly, has there already been some effort put towards this that I
>>>>> have missed?
>>>>> Secondly, I have never contributed to a GitHub project before. What
>>>>> is the best way to approach it? I imagine I will want some
>>>>> review/discussion before merging anything. Do I do a Fork and then speak
>>>>> to one of the core team re merging?
Ah now it makes sense, for some reason I had it in my head that you wanted
to have a service on Metro, not a client. Feel free to contact me and we'll
chat -- I have a pretty in depth understanding of both the .NET framework
and dynamic generation, but haven't looked at the clients much, so
hopefully we can figure out an attack plan pretty quickly.
On Wed, Nov 14, 2012 at 12:10 PM, Demis Bellot <demis.bel...@gmail.com>wrote:
> Most of the support for the different platforms have been contributed to
> by the community of different platforms wanting to see support for it.
> So far there have been little interest to add support Windows 8, I think
> @gshackles is having a go at supporting it, although I'm not sure how far
> he's got.
> On Tue, Nov 13, 2012 at 5:27 PM, David Churchland <david.churchl...@hp.com
> > wrote:
>> Sorry, I did not notice this reply.
>> The use scenario for Metro (or more accurately Windows Store App) is so
>> that I can consume a service stack service using the servicestack client
>> from a Windows Store App. The Windows Store .Net framework is a much
>> reduced version of the .Net 4.5 framework.
>> Am I being dense? I assumed this would be just as obvious a use case as
>> MonoTouch? Is there some reason I have missed that there seems to be
>> relatively little interest in this?
>> On Tuesday, 6 November 2012 08:00:33 UTC+11, Mikkel Fishman wrote:
>>> Perhaps I'm dense, but what is the use scenario for having support for
>>> metro? I'm planning on making a metro app soon so may be able to contribute.
>>> On Monday, October 29, 2012 6:14:37 PM UTC+13, David Churchland wrote:
>>>> I have followed just the approach you suggest, using Monotouch etc as a
>>>> guide.
>>>> Unfortunately I don't think much can be done using plugins as the .Net
>>>> Reflection classes have changed, for example there are many places where
>>>> Type.GetTypeInfo() is required, for example type.GetTypeInfo().**IsEnum
>>>> rather than type.IsEnum.
>>>> I will play with it and dro pyou a note if I need clarification on
>>>> anything in particular.
>>>> On Monday, 29 October 2012 15:57:40 UTC+11, mythz wrote:
>>>>> Hi David,
>>>>> I'm not aware of any current effort to add support for Metro. There
>>>>> was some mention of someone attempting it a long time ago, but I've never
>>>>> heard back from them so I don't expect that effort still exists.
>>>>> For contributing to GitHub, you basically just want to fork the
>>>>> repository you want to work on.
>>>>> Add your changes on your own fork, and then when the changes have been
>>>>> tested and are ready for merging, just issue a pull-request:
>>>>> Basically if you want to do any disruptive changes or are unsure
>>>>> whether a feature should be added to the main project, you should consult
>>>>> this list. Most new features should ideally be added via plugins<https://github.com/ServiceStack/ServiceStack/wiki/Plugins>
>>>>> .
>>>>> If you want to add support for a different platform, then we just use
>>>>> #define build symbols, there's plenty of examples in the ServiceStack.Text
>>>>> and ServiceStack.Common code-bases. Basically each new platform should take
>>>>> a copy of the project file in its own directory, and the VS.NETproject should include the build symbol for your platform, see the
>>>>> different platforms in ServiceStack.Text as an example:
>>>>> https://github.com/**ServiceStack/ServiceStack.**Text/tree/master/src<https://github.com/ServiceStack/ServiceStack.Text/tree/master/src>
>>>>> Only the client libraries (e.g. ServiceStack.Text +
>>>>> ServiceStack.Common) are needed in order to call ServiceStack services.
>>>>> Thanks,
>>>>> On Sun, Oct 28, 2012 at 11:15 PM, David Churchland <david.ch...@hp.com
>>>>> > wrote:
>>>>>> I am part way through a rough port of ServiceStack to work with .NET
>>>>>> APIs for Metro style apps.
>>>>>> Firstly, has there already been some effort put towards this that I
>>>>>> have missed?
>>>>>> Secondly, I have never contributed to a GitHub project before. What
>>>>>> is the best way to approach it? I imagine I will want some
>>>>>> review/discussion before merging anything. Do I do a Fork and then speak
>>>>>> to one of the core team re merging?
The terminology is so confusing here. What sort of Windows Store App are
you talking about? My company has a WSA/HTML5 app that uses a servicestack
API and it required nothing special. I expect you're talking about XAML/C#?
On Tue, Nov 13, 2012 at 3:10 PM, Demis Bellot <demis.bel...@gmail.com>wrote:
> Most of the support for the different platforms have been contributed to
> by the community of different platforms wanting to see support for it.
> So far there have been little interest to add support Windows 8, I think
> @gshackles is having a go at supporting it, although I'm not sure how far
> he's got.
> On Tue, Nov 13, 2012 at 5:27 PM, David Churchland <david.churchl...@hp.com
> > wrote:
>> Sorry, I did not notice this reply.
>> The use scenario for Metro (or more accurately Windows Store App) is so
>> that I can consume a service stack service using the servicestack client
>> from a Windows Store App. The Windows Store .Net framework is a much
>> reduced version of the .Net 4.5 framework.
>> Am I being dense? I assumed this would be just as obvious a use case as
>> MonoTouch? Is there some reason I have missed that there seems to be
>> relatively little interest in this?
>> On Tuesday, 6 November 2012 08:00:33 UTC+11, Mikkel Fishman wrote:
>>> Perhaps I'm dense, but what is the use scenario for having support for
>>> metro? I'm planning on making a metro app soon so may be able to contribute.
>>> On Monday, October 29, 2012 6:14:37 PM UTC+13, David Churchland wrote:
>>>> I have followed just the approach you suggest, using Monotouch etc as a
>>>> guide.
>>>> Unfortunately I don't think much can be done using plugins as the .Net
>>>> Reflection classes have changed, for example there are many places where
>>>> Type.GetTypeInfo() is required, for example type.GetTypeInfo().**IsEnum
>>>> rather than type.IsEnum.
>>>> I will play with it and dro pyou a note if I need clarification on
>>>> anything in particular.
>>>> On Monday, 29 October 2012 15:57:40 UTC+11, mythz wrote:
>>>>> Hi David,
>>>>> I'm not aware of any current effort to add support for Metro. There
>>>>> was some mention of someone attempting it a long time ago, but I've never
>>>>> heard back from them so I don't expect that effort still exists.
>>>>> For contributing to GitHub, you basically just want to fork the
>>>>> repository you want to work on.
>>>>> Add your changes on your own fork, and then when the changes have been
>>>>> tested and are ready for merging, just issue a pull-request:
>>>>> Basically if you want to do any disruptive changes or are unsure
>>>>> whether a feature should be added to the main project, you should consult
>>>>> this list. Most new features should ideally be added via plugins<https://github.com/ServiceStack/ServiceStack/wiki/Plugins>
>>>>> .
>>>>> If you want to add support for a different platform, then we just use
>>>>> #define build symbols, there's plenty of examples in the ServiceStack.Text
>>>>> and ServiceStack.Common code-bases. Basically each new platform should take
>>>>> a copy of the project file in its own directory, and the VS.NETproject should include the build symbol for your platform, see the
>>>>> different platforms in ServiceStack.Text as an example:
>>>>> https://github.com/**ServiceStack/ServiceStack.**Text/tree/master/src<https://github.com/ServiceStack/ServiceStack.Text/tree/master/src>
>>>>> Only the client libraries (e.g. ServiceStack.Text +
>>>>> ServiceStack.Common) are needed in order to call ServiceStack services.
>>>>> Thanks,
>>>>> On Sun, Oct 28, 2012 at 11:15 PM, David Churchland <david.ch...@hp.com
>>>>> > wrote:
>>>>>> I am part way through a rough port of ServiceStack to work with .NET
>>>>>> APIs for Metro style apps.
>>>>>> Firstly, has there already been some effort put towards this that I
>>>>>> have missed?
>>>>>> Secondly, I have never contributed to a GitHub project before. What
>>>>>> is the best way to approach it? I imagine I will want some
>>>>>> review/discussion before merging anything. Do I do a Fork and then speak
>>>>>> to one of the core team re merging?
As is often the way my attention had been diverted by other priorities Shawn's post has caused me to re-consider what I am doing. I assume that the WSA approach will mean that networking and serialization etc. will be handled by the web stack.
This may well be our preferred approach, I have not experimented with web stack support in Win 8 yet. In my wildest dreams we might be able to share some of our code between a web stack app and a pure web app.
More thought and experimentation required from me.
On Wednesday, 14 November 2012 11:20:06 UTC+11, Shawn Hinsey wrote:
> The terminology is so confusing here. What sort of Windows Store App are > you talking about? My company has a WSA/HTML5 app that uses a servicestack > API and it required nothing special. I expect you're talking about XAML/C#?
> On Tue, Nov 13, 2012 at 3:10 PM, Demis Bellot <demis....@gmail.com<javascript:> > > wrote:
>> Most of the support for the different platforms have been contributed to >> by the community of different platforms wanting to see support for it. >> So far there have been little interest to add support Windows 8, I think >> @gshackles is having a go at supporting it, although I'm not sure how far >> he's got.
>> On Tue, Nov 13, 2012 at 5:27 PM, David Churchland <david.ch...@hp.com<javascript:> >> > wrote:
>>> Sorry, I did not notice this reply.
>>> The use scenario for Metro (or more accurately Windows Store App) is so >>> that I can consume a service stack service using the servicestack client >>> from a Windows Store App. The Windows Store .Net framework is a much >>> reduced version of the .Net 4.5 framework.
>>> Am I being dense? I assumed this would be just as obvious a use case as >>> MonoTouch? Is there some reason I have missed that there seems to be >>> relatively little interest in this?
>>> On Tuesday, 6 November 2012 08:00:33 UTC+11, Mikkel Fishman wrote:
>>>> Perhaps I'm dense, but what is the use scenario for having support for >>>> metro? I'm planning on making a metro app soon so may be able to contribute.
>>>> On Monday, October 29, 2012 6:14:37 PM UTC+13, David Churchland wrote:
>>>>> I have followed just the approach you suggest, using Monotouch etc as >>>>> a guide.
>>>>> Unfortunately I don't think much can be done using plugins as the .Net >>>>> Reflection classes have changed, for example there are many places where >>>>> Type.GetTypeInfo() is required, for example type.GetTypeInfo().**IsEnum >>>>> rather than type.IsEnum.
>>>>> I will play with it and dro pyou a note if I need clarification on >>>>> anything in particular.
>>>>> On Monday, 29 October 2012 15:57:40 UTC+11, mythz wrote:
>>>>>> Hi David,
>>>>>> I'm not aware of any current effort to add support for Metro. There >>>>>> was some mention of someone attempting it a long time ago, but I've never >>>>>> heard back from them so I don't expect that effort still exists.
>>>>>> For contributing to GitHub, you basically just want to fork the >>>>>> repository you want to work on. >>>>>> Add your changes on your own fork, and then when the changes have >>>>>> been tested and are ready for merging, just issue a pull-request:
>>>>>> Basically if you want to do any disruptive changes or are unsure >>>>>> whether a feature should be added to the main project, you should consult >>>>>> this list. Most new features should ideally be added via plugins<https://github.com/ServiceStack/ServiceStack/wiki/Plugins> >>>>>> .
>>>>>> If you want to add support for a different platform, then we just use >>>>>> #define build symbols, there's plenty of examples in the ServiceStack.Text >>>>>> and ServiceStack.Common code-bases. Basically each new platform should take >>>>>> a copy of the project file in its own directory, and the VS.NETproject should include the build symbol for your platform, see the >>>>>> different platforms in ServiceStack.Text as an example: >>>>>> https://github.com/**ServiceStack/ServiceStack.**Text/tree/master/src<https://github.com/ServiceStack/ServiceStack.Text/tree/master/src>
>>>>>> Only the client libraries (e.g. ServiceStack.Text + >>>>>> ServiceStack.Common) are needed in order to call ServiceStack services.
>>>>>> Thanks,
>>>>>> On Sun, Oct 28, 2012 at 11:15 PM, David Churchland < >>>>>> david.ch...@hp.com> wrote:
>>>>>>> I am part way through a rough port of ServiceStack to work with .NET >>>>>>> APIs for Metro style apps.
>>>>>>> Firstly, has there already been some effort put towards this that I >>>>>>> have missed?
>>>>>>> Secondly, I have never contributed to a GitHub project before. What >>>>>>> is the best way to approach it? I imagine I will want some >>>>>>> review/discussion before merging anything. Do I do a Fork and then speak >>>>>>> to one of the core team re merging?
Yeah I agree, the HTML5 apps need nothing special. That said, my particular
app is going to target XAML initially due to performance concerns about
rich JS/HTML5 apps so I'll probably be looking into making a client at some
point. After looking at the .NET framework for the store apps it shouldn't
be too bad of a port at all.
On Wed, Nov 14, 2012 at 1:32 PM, David Churchland
<david.churchl...@hp.com>wrote:
> As is often the way my attention had been diverted by other priorities
> Shawn's post has caused me to re-consider what I am doing. I assume that
> the WSA approach will mean that networking and serialization etc. will be
> handled by the web stack.
> This may well be our preferred approach, I have not experimented with web
> stack support in Win 8 yet. In my wildest dreams we might be able to share
> some of our code between a web stack app and a pure web app.
> More thought and experimentation required from me.
> thanks guys.
> On Wednesday, 14 November 2012 11:20:06 UTC+11, Shawn Hinsey wrote:
>> The terminology is so confusing here. What sort of Windows Store App are
>> you talking about? My company has a WSA/HTML5 app that uses a servicestack
>> API and it required nothing special. I expect you're talking about XAML/C#?
>> On Tue, Nov 13, 2012 at 3:10 PM, Demis Bellot <demis....@gmail.com>wrote:
>>> Most of the support for the different platforms have been contributed to
>>> by the community of different platforms wanting to see support for it.
>>> So far there have been little interest to add support Windows 8, I think
>>> @gshackles is having a go at supporting it, although I'm not sure how far
>>> he's got.
>>> On Tue, Nov 13, 2012 at 5:27 PM, David Churchland <david.ch...@hp.com>wrote:
>>>> Sorry, I did not notice this reply.
>>>> The use scenario for Metro (or more accurately Windows Store App) is so
>>>> that I can consume a service stack service using the servicestack client
>>>> from a Windows Store App. The Windows Store .Net framework is a much
>>>> reduced version of the .Net 4.5 framework.
>>>> Am I being dense? I assumed this would be just as obvious a use case
>>>> as MonoTouch? Is there some reason I have missed that there seems to be
>>>> relatively little interest in this?
>>>> On Tuesday, 6 November 2012 08:00:33 UTC+11, Mikkel Fishman wrote:
>>>>> Perhaps I'm dense, but what is the use scenario for having support for
>>>>> metro? I'm planning on making a metro app soon so may be able to contribute.
>>>>> On Monday, October 29, 2012 6:14:37 PM UTC+13, David Churchland wrote:
>>>>>> I have followed just the approach you suggest, using Monotouch etc as
>>>>>> a guide.
>>>>>> Unfortunately I don't think much can be done using plugins as the
>>>>>> .Net Reflection classes have changed, for example there are many places
>>>>>> where Type.GetTypeInfo() is required, for example type.GetTypeInfo().
>>>>>> **IsE**num rather than type.IsEnum.
>>>>>> I will play with it and dro pyou a note if I need clarification on
>>>>>> anything in particular.
>>>>>> On Monday, 29 October 2012 15:57:40 UTC+11, mythz wrote:
>>>>>>> Hi David,
>>>>>>> I'm not aware of any current effort to add support for Metro. There
>>>>>>> was some mention of someone attempting it a long time ago, but I've never
>>>>>>> heard back from them so I don't expect that effort still exists.
>>>>>>> For contributing to GitHub, you basically just want to fork the
>>>>>>> repository you want to work on.
>>>>>>> Add your changes on your own fork, and then when the changes have
>>>>>>> been tested and are ready for merging, just issue a pull-request:
>>>>>>> Basically if you want to do any disruptive changes or are unsure
>>>>>>> whether a feature should be added to the main project, you should consult
>>>>>>> this list. Most new features should ideally be added via plugins<https://github.com/ServiceStack/ServiceStack/wiki/Plugins>
>>>>>>> .
>>>>>>> If you want to add support for a different platform, then we just
>>>>>>> use #define build symbols, there's plenty of examples in the
>>>>>>> ServiceStack.Text and ServiceStack.Common code-bases. Basically each new
>>>>>>> platform should take a copy of the project file in its own directory, and
>>>>>>> the VS.NET project should include the build symbol for your
>>>>>>> platform, see the different platforms in ServiceStack.Text as an example:
>>>>>>> https://github.com/**ServiceStac**k/ServiceStack.**Text/tree/** >>>>>>> master/src<https://github.com/ServiceStack/ServiceStack.Text/tree/master/src>
>>>>>>> Only the client libraries (e.g. ServiceStack.Text +
>>>>>>> ServiceStack.Common) are needed in order to call ServiceStack services.
>>>>>>> Thanks,
>>>>>>> On Sun, Oct 28, 2012 at 11:15 PM, David Churchland <
>>>>>>> david.ch...@hp.com> wrote:
>>>>>>>> I am part way through a rough port of ServiceStack to work with .NET
>>>>>>>> APIs for Metro style apps.
>>>>>>>> Firstly, has there already been some effort put towards this that
>>>>>>>> I have missed?
>>>>>>>> Secondly, I have never contributed to a GitHub project before.
>>>>>>>> What is the best way to approach it? I imagine I will want some
>>>>>>>> review/discussion before merging anything. Do I do a Fork and then speak
>>>>>>>> to one of the core team re merging?
Ours was a port from an existing mobile web app and we were basically able
to reuse everything. There is definitely a learning curve due to the
uncanny valley not-quite-the-HTML-you're-used-to nature of it, but I was
able to reuse core API level JS code without modification.
On Tue, Nov 13, 2012 at 4:32 PM, David Churchland
<david.churchl...@hp.com>wrote:
> As is often the way my attention had been diverted by other priorities
> Shawn's post has caused me to re-consider what I am doing. I assume that
> the WSA approach will mean that networking and serialization etc. will be
> handled by the web stack.
> This may well be our preferred approach, I have not experimented with web
> stack support in Win 8 yet. In my wildest dreams we might be able to share
> some of our code between a web stack app and a pure web app.
> More thought and experimentation required from me.
> thanks guys.
> On Wednesday, 14 November 2012 11:20:06 UTC+11, Shawn Hinsey wrote:
>> The terminology is so confusing here. What sort of Windows Store App are
>> you talking about? My company has a WSA/HTML5 app that uses a servicestack
>> API and it required nothing special. I expect you're talking about XAML/C#?
>> On Tue, Nov 13, 2012 at 3:10 PM, Demis Bellot <demis....@gmail.com>wrote:
>>> Most of the support for the different platforms have been contributed
>>> to by the community of different platforms wanting to see support for it.
>>> So far there have been little interest to add support Windows 8, I think
>>> @gshackles is having a go at supporting it, although I'm not sure how far
>>> he's got.
>>> On Tue, Nov 13, 2012 at 5:27 PM, David Churchland <david.ch...@hp.com>wrote:
>>>> Sorry, I did not notice this reply.
>>>> The use scenario for Metro (or more accurately Windows Store App) is so
>>>> that I can consume a service stack service using the servicestack client
>>>> from a Windows Store App. The Windows Store .Net framework is a much
>>>> reduced version of the .Net 4.5 framework.
>>>> Am I being dense? I assumed this would be just as obvious a use case
>>>> as MonoTouch? Is there some reason I have missed that there seems to be
>>>> relatively little interest in this?
>>>> On Tuesday, 6 November 2012 08:00:33 UTC+11, Mikkel Fishman wrote:
>>>>> Perhaps I'm dense, but what is the use scenario for having support for
>>>>> metro? I'm planning on making a metro app soon so may be able to contribute.
>>>>> On Monday, October 29, 2012 6:14:37 PM UTC+13, David Churchland wrote:
>>>>>> I have followed just the approach you suggest, using Monotouch etc as
>>>>>> a guide.
>>>>>> Unfortunately I don't think much can be done using plugins as the
>>>>>> .Net Reflection classes have changed, for example there are many places
>>>>>> where Type.GetTypeInfo() is required, for example type.GetTypeInfo().
>>>>>> **IsE**num rather than type.IsEnum.
>>>>>> I will play with it and dro pyou a note if I need clarification on
>>>>>> anything in particular.
>>>>>> On Monday, 29 October 2012 15:57:40 UTC+11, mythz wrote:
>>>>>>> Hi David,
>>>>>>> I'm not aware of any current effort to add support for Metro. There
>>>>>>> was some mention of someone attempting it a long time ago, but I've never
>>>>>>> heard back from them so I don't expect that effort still exists.
>>>>>>> For contributing to GitHub, you basically just want to fork the
>>>>>>> repository you want to work on.
>>>>>>> Add your changes on your own fork, and then when the changes have
>>>>>>> been tested and are ready for merging, just issue a pull-request:
>>>>>>> Basically if you want to do any disruptive changes or are unsure
>>>>>>> whether a feature should be added to the main project, you should consult
>>>>>>> this list. Most new features should ideally be added via plugins<https://github.com/ServiceStack/ServiceStack/wiki/Plugins>
>>>>>>> .
>>>>>>> If you want to add support for a different platform, then we just
>>>>>>> use #define build symbols, there's plenty of examples in the
>>>>>>> ServiceStack.Text and ServiceStack.Common code-bases. Basically each new
>>>>>>> platform should take a copy of the project file in its own directory, and
>>>>>>> the VS.NET project should include the build symbol for your
>>>>>>> platform, see the different platforms in ServiceStack.Text as an example:
>>>>>>> https://github.com/**ServiceStac**k/ServiceStack.**Text/tree/** >>>>>>> master/src<https://github.com/ServiceStack/ServiceStack.Text/tree/master/src>
>>>>>>> Only the client libraries (e.g. ServiceStack.Text +
>>>>>>> ServiceStack.Common) are needed in order to call ServiceStack services.
>>>>>>> Thanks,
>>>>>>> On Sun, Oct 28, 2012 at 11:15 PM, David Churchland <
>>>>>>> david.ch...@hp.com> wrote:
>>>>>>>> I am part way through a rough port of ServiceStack to work with .NET
>>>>>>>> APIs for Metro style apps.
>>>>>>>> Firstly, has there already been some effort put towards this that
>>>>>>>> I have missed?
>>>>>>>> Secondly, I have never contributed to a GitHub project before.
>>>>>>>> What is the best way to approach it? I imagine I will want some
>>>>>>>> review/discussion before merging anything. Do I do a Fork and then speak
>>>>>>>> to one of the core team re merging?
