Ideas (feature requests)

[Alexey Solonets]

Hi Gian Marco!

I have some new thoughts. Want to know your mention about.

1. Separate APIs by areas (zones).

For example I have 'Admin' page which uses a lot of Direct services. This page is used rarely. But huge admin's API is always loaded on /rpc. So I want to register some services in separate zone so that it look like:

configurator.RegisterType(typeof(MyCommonService));

configurator.RegisterType(typeof(MyAdminService), "ADMIN_REMOTING_API");

and then include second API only in admin pages:

<script type="text/javascript" src="/MyWebSite/rpc"></script>

<script type="text/javascript" src="/MyWebSite/rpc?name=ADMIN_REMOTING_API"></script>

so second response will be

Ext.ns('Ext.app');

Ext.app.ADMIN_REMOTING_API = {

"id": null,

"url": "http://localhost/MyWebSite/rpc",

"type": "remoting",

"namespace": null,

"actions": { 

...

and then I can register it in the page

<script type="text/javascript">

Ext.direct.Manager.addProvider(Ext.app.REMOTING_API);

Ext.direct.Manager.addProvider(Ext.app.ADMIN_REMOTING_API);

...

</script>

Admin page is only for example. Actually there are a lot of independent services which APIs are used only in corresponding pages.

2. Parallel (async) action execution inside a HTTP-request.

I have a situation when I need to execute about 15 actions at once. Each one takes about 25-30ms. So overall it takes close to 500ms.

I'm sure that parallel execution can reduce response time much.

Maybe not all actions should be executed async and we should configure it somewhere in attribute:

[DirectMethod(NamedArguments=true, Async=true)]

I want to try to realize these features at an early date. But first what do you think about it?

[Gian Marco Gherardi]

Hi, my toughts in the proposals:

1. Separate APIs by areas (zones).

Not a trivial implementation. If the problem is in API definition size, a simple solution can be to minimize the generated javascript, if i remember correctly it is currently generated with spaces and indentation.

2. Parallel (async) action execution inside a HTTP-request.

Not trivial at all. to have ExtDirect method calls executed in parallel the best solution for me is to set enableBuffer to false. See http://docs.sencha.com/ext-js/4-1/#!/api/Ext.direct.RemotingProvider-cfg-enableBuffer

Gian Marco Gherardi
http://gianmarco.gherardi.me

[Alexey Solonets]

2. Parallel (async) action execution inside a HTTP-request.

Yeah, switched off the buffer. Got much better. Let IIS think about parallel execution :)

1. Separate APIs by areas (zones).

Minimization is not a solution. In my case project will grow and API definition will be really huge. I don't like it by design :( It should be possible to split it. Moreover I want to control even the RemotingProvider with all it's configs such as id, enableBuffer, timeout etc. So maybe it will be good to register providers too:

configurator.RegisterProvider(new RemotingProvider() 

{ 

    Id = "custom",

    EnableBuffer = false,

    Actions = new [] { typeof(CustomService) }

});

and then 

<script type="text/javascript" src="/MyWebSite/rpc?id=custom"></script>

I like this idea ;) Again, I don't ask you to implement it. I'll try to do it by myself in free time.

--
Alexey Solonets

[Gian Marco Gherardi]

For the zone issue, another possible implementation is to make ExtDirectHttpHandler independent from the static data in it, this will enable the creation of more specialized handlers (using inheritance) that can be configured and registered independently. You then have more than one handler exposed and you can use this way:

<script type="text/javascript" src="/MyWebSite/handler1"></script>

<script type="text/javascript" src="/MyWebSite/handler2"></script>

Gian Marco Gherardi
http://gianmarco.gherardi.me

[Alexey Solonets]

Hi Gian Marco!

I have some news for you.

1. Found small bug in ReflectionConfigurator.cs when all actions were registered.

mi.DeclaringType == type || _reflectionHelpers.HasAttribute<DirectMethodAttribute>(mi)

2. Back to parallel execution. Nevertheless I  tried to implement it and it took 3 lines of code. And it is extremely fast. Whole query with a lot of actions executes as long as it takes for longest action to execute (hope my english is good enough to explain correctly ;) I'm exited overall. Here is the code you can play with (just for fun)

private void DoPost(HttpRequest httpRequest, HttpResponse httpResponse)

...

for(int i = 0; i < requests.Length; i++)

{

new Thread((object idx) =>

{

responses[(int)idx] = new DirectHandler(_metadata, _directHandlerInterceptor).Handle(requests[(int)idx]);

}).Start(i);

}

while (responses.Any(r => r == null)) { Thread.Sleep(1); }

...

3. More serious. I like your idea to make DirectHttpHandler independed from it's static data. But I'm stuck with few things. First of all do you want to make it backward compatible? Second is how do you imagine registration of independent handlers? Where should registration be located at? Inside a constructor? I started trying to do something and found that either I will have to register each handler in web.config or use them as-is (e.g. http://.../handler1.ashx). Not sure that I like any of these options.

Still in my vision there is should be single entry point (http://../rpc) for querying info about actions and executing them. Same as registration - all in one place.

What are your thoughts?

--
Alexey Solonets

[Gian Marco Gherardi]

> do you want to make it backward compatible?

If possible, yes.

> Second is how do you imagine registration of independent handlers?

Like you said, they are independent, so will be registered like all asp.net handlers.

> Where should registration be located at? Inside a constructor?

Constructor or other method override.

When implementing feature like these, what i'm trying to do is reuse what is already supported in .NET/AspNet/IIS. Maybe defining all your handlers in web.config is not handy, but that's how AspNet works.

PS: other than web.config, ASPNET also support Microsoft.Web.Infrastructure.DynamicModuleHelper

Gian Marco Gherardi
http://gianmarco.gherardi.me