Some MidCOM3 API changes to come
-
Henri Bergius
Some MidCOM3 API changes to come
Thu August 28 2008 10:39:53 UTCHi, all
While our focus currently is on Ragnaroek stabilization, I've had some
discussions with Tero about needed changes to MidCOM3 API. I'm not
sure when I will have the time to work on these, but probably during
early September.
The reason why I wanted to bring these up is that Tero's group is
actually building a production site with MidCOM3 at the moment, and so
it is important for them to know what will be changing.
So, some points:
* Changes to controller API
- I want to tie controller actions tighter to HTTP methods. This
means that instead of action_xx we should have get_xx, post_xx, put_xx
etc
This will make supporting WebDAV and Neutron from components a lot easier
- We have been talking of supporting "controller proxying", i.e.
calling a remote controller via HTTP API. For this we need to limit
controller's
access to environment information to two things: argument array
and the current context (data from $_MIDCOM->context)
* Moving WebDAV handling from dispatcher to core
- Now dispatcher looks at request type and either invokes WebDAV
server or the controller. This should be done in $_MIDCOM->process()
instead
* Context injectors
- In order to keep out-of-the-box context data relatively clean, I
want to introduce context injectors that components could provide via
their manifest
Injectors could be things like org_routamc_positioning adding
user's current location to context. Context injectors would be run
before process() phase
- See http://worrydream.com/MagicInk/#inferring_context_from_the_environment
for what we could do with context
- If controllers use obscure context keys, then they must first check if isset
* Caching infrastructure
- We need to start porting MidCOM2 caching services to MidCOM3
In another note about MidCOM3, it seems we're doing quite well
performance-wise. On my benchmarks, a MidCOM3 static page on Midgard2
ran faster than a plain PHP "echo hello world" file from Apache
without APC. Not bad! But there are still many things to improve, for
example by caching midgard_request_config on core level.
/Bergie
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: Some MidCOM3 API changes to come
Thu August 28 2008 11:07:23 UTCThe reason why I wanted to bring these up is that Tero's group is actually building a production site with MidCOM3 at the moment, and so it is important for them to know what will be changing.
Another thing I forgot to mention:
In FrOSCon I saw a pretty inspiring presentation about Dropr - a generic message queue for PHP5:
I would like to build some parts of MidCOM with Dropr in mind. A generic message queue could provide interesting new possibilities, like:
- Replace our replication-specific message queue (what the replicator essentially was)
- Enable handing of computing-intensive tasks like karma calculations or data imports to other nodes, and then replicate ready results back
Dropr seemed simple enough, and supporting asynchronous, remote processing would be a quite powerful concept for larger, cloud-oriented Midgard environments.
http://bergie.iki.fi/blog/midgard2-future_in_the_clouds.html
This is not something that developers of simple websites need, but would be useful for already environments like maemo.org
/Bergie
-
Re: [midgard-dev] Some MidCOM3 API changes to come
Thu August 28 2008 13:39:18 UTCHenri Bergius writes:
> Hi, all
Hi!
> So, some points:
>
> * Changes to controller API
> - I want to tie controller actions tighter to HTTP methods. This
> means that instead of action_xx we should have get_xx, post_xx, put_xx
> etc
Does it mean, MidCOM3 will be pure web environment oriented?
> In another note about MidCOM3, it seems we're doing quite well
> performance-wise. On my benchmarks, a MidCOM3 static page on Midgard2
> ran faster than a plain PHP "echo hello world" file from Apache
> without APC. Not bad!
I think that we need to give some load to plain PHP file to see real
difference.
* include at least simple DB framework and make DB connection
* define 20~30 simple classes with default properties ( 20~30 per every
class )
* parse url simple way
Those tasks are already done at Midgard request startup, so to be fair,
plain PHP should do the same.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Some MidCOM3 API changes to come
Fri August 29 2008 09:00:33 UTCHi,
On Thu, Aug 28, 2008 at 4:39 PM, Piotr Pokora <piotrek.pokora@gmail.com> wrote:
>> - I want to tie controller actions tighter to HTTP methods
> Does it mean, MidCOM3 will be pure web environment oriented?
Not at all. CLI scripts can either "map themselves" to a desired HTTP
method (mainly GET and POST), or state themselves as a separate "cli"
action. The manual dispatcher in MidCOM3 will be modified to make this
easier.
> I think that we need to give some load to plain PHP file to see real
> difference.
>
> * include at least simple DB framework and make DB connection
> * define 20~30 simple classes with default properties ( 20~30 per every
> class )
> * parse url simple way
Well, we both know Midgard, which is done in C, is faster than PHP
script doing those. The big question is that whether we could get
close of the "hello world" speeds with more efficient caching. That'd
kill Rasmus' arguments that "frameworks suck" ;-)
> Piotras
/Bergie
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Some MidCOM3 API changes to come
Fri August 29 2008 09:27:30 UTCHenri Bergius writes:
> Hi,
Hi!
>> I think that we need to give some load to plain PHP file to see real
>> difference.
>>
>> * include at least simple DB framework and make DB connection
>> * define 20~30 simple classes with default properties ( 20~30 per every
>> class )
>> * parse url simple way
>
> Well, we both know Midgard, which is done in C, is faster than PHP
> script doing those. The big question is that whether we could get
> close of the "hello world" speeds with more efficient caching. That'd
> kill Rasmus' arguments that "frameworks suck" ;-)
Yes. Making a van car faster than F1 seems to be cool, but we also need
to prove that this van car is better than tank ;)
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: Some MidCOM3 API changes to come
Tue September 02 2008 14:56:00 UTC- Context injectors
All right, context injectors are now in:
http://bergie.iki.fi/blog/midcom_3_and_context_injectors.html
/Bergie
