[Web] discussion with mst on #catalyst

[Carl Mäsak]

This email might interest those who are involved in Web.pm design. It
consists of a slightly curated chat log from yesterday. At the bottom
are links to relevant modules that were mentioned in the discussions.

I got into a discussion on #perl6 about Web.pm being a Perl 6 Catalyst...

<ruoso> and for starters, I'd warn that "DispatchType" was the biggest
mistake in Catalyst...
<ruoso> so, don't repeat it ;)
<masak> ruoso: ok. any links?
<ruoso> make other mistakes instead
<ruoso> masak, unfortunally I don't have any links to that...
<masak> ruoso: ok, I'll try to do some research myself.
<ruoso> but basically, if you use more than one dispatch type in an application
<masak> ruoso: thanks for the pointer.
<ruoso> it will blow in your face
<ruoso> not with an error,
<PerlJam> heh ... we'll show those ruby folks what a DSL really looks like! ;)
<masak> ruoso: dispatch type?
<ruoso> but with unpredictable behaviour
<ruoso> :Path, :Regex, :Chained
<ruoso> make everything a variation of :Chained
<ruoso> if you talk with mst, he'll explain that in detail
* masak is in over his head already
<masak> I'll talk to mst.
* ruoso also does a kind warning about mst mood, which is mostly hard
to deal with
<ruoso> ;)
<masak> :)

A few minutes later, on #catalyst:

<masak> greetings. I'm looking for historical notes on DispatchType.
does anyone have any pointers?
<mst> historical notes?
<PerlJam> heh
<masak> yes, I'm trying not to repeat history.
<mst> well, there's the svn logs
<mst> there's also me.
<mst> since I wrote that
<masak> ok.
<masak> mst: is it possible to give a short summary of it?
<mst> er, the summary is "look at how the dispatcher calls them"
<PerlJam> masak: you may want to clue mst in on what you're doing in
case it's relevant :)
<mst> oh, also, crack open a pre-5.50 catalyst dispatcher
<masak> PerlJam: oh, ok.
<mst> once you've done that, maybe you could ask something less vague?
<mst> or even explain what you're trying to write
<mst> so I have some idea what to tell you
<masak> we're writing a web toolkit for Perl 6.
<mst> ok
<mst> then the answer is:
<masak> including dispatchers, templating and MVC.
<mst> (1) I want to rewrite the dispatcher
<mst> (2) Path::Dispatcher is closer to what I want
<mst> (3) I'm fairly convinced you can do an entire dispatcher as
chained multimethod dispatch
* masak likes (3)
<masak> that sounds promising for Perl 6
<PerlJam> indeed
<mst> it's promising for perl5
<mst> since we already have most of the work done to do multimethods
<masak> mst: have you looked at Jifty's dispatcher?
<mst> Path::Dispatcher was factored out of it
<mst> cleaning up most of the design mistakes in the process
<masak> ok.
<masak> I'll look at that, then.
<mst> so yes, I have, but you shouldn't waste your time
<masak> :)
<theorbtwo> It might be useful to know what the remaning design mistakes are...
<masak> definitely.
<mst> well, lack of context, which has now been fixed
<mst> the interesting problem is trying to not make it path-centric
<mst> without making the simple places complicated
<mst> I don't really have an answer yet
<masak> what could 'not path-centric' mean?
<mst> I suggest you experiment
<mst> since you're not working on production code
<mst> you can afford to be weirder than I can
<masak> good suggestion.
<mst> I have business users and backcompat to worry about
<masak> :)
<mst> vapor6 isn't going to for some time
<PerlJam> masak: I see from the PLAN that you're taking inspiration
from ruby-land. This is good, but don't let it constrain you.
<masak> PerlJam: okiedokie.
<mst> don't take inspiration from ruby land for OO code
<masak> :)
<mst> stick to things with a decent object model
<masak> no, we have enough OO in Perl 6 as it is.
<mst> right, but my point is their code is constrained by their crappy
object system
<masak> right.
<masak> I'm reluctant to do a lot of monkey patching, which Rails
seems to be doing.
<PerlJam> rails is all about monkey patching
<masak> yes, but I think it can be just as good without it.
<mst> what you want is to handle things via role application and
generation of classes at runtime
<mst> look at something like MooseX::Object::Pluggable
<masak> indeed.
<mst> then consider what happens when you do that to an entire class tree
<mst> which is what we'll be doing in 5.80 :)
<PerlJam> masak: if you guys can get to dogfooding like november does,
that would be awesome. What's the timeline for the grant again? 2
months?
<masak> 11 weeks.
<PerlJam> ah, good.
<masak> dogfooding occurs somewhere in week 4 or 5.
* mst notes that jifty would probably have been built atop catalyst if
sri had left earlier
<PerlJam> masak: and I think you're an optimist :)
<mst> since his departure was the point at which we started
guaranteeing backcompat :)
<PerlJam> masak: or maybe I'm a pessimist about dog food :)
<mst> masak: look at HTTP::Engine as well
<masak> ok.
<mst> build everything as pluggable as possible
<masak> aye.
<mst> ideally, you should be able to bolt together a CGI::Application
level thing
<mst> up to a Catalyst or a Jifty
<mst> from the same set of components
<mst> that's where -we- intend to be
<masak> mst: I don't know you, but I like you already.
<masak> you're the first one who understands our project.
<mst> hah
<mst> that's because you're doing the same things I want to do with
the perl5 stack
<masak> probably, yes.

...later...

<masak> fyi, I'm currently curating the first part of our discussion
for sending to the november-wiki list, where Web discussion takes
place.
<mst> by all means
<mst> I'd be delighted to chat design with you on and off
<masak> me too.
<mst> might help me solidify my ideas for the future of catalyst
<masak> aye.
<mst> and I can point out when you're about to do something I already
learned the hard way was a bad idea
<masak> I expect to do a steep climb learning about Web frameworks in
the next couple weeks.
<mst> thus giving you more time to make different mistakes I can avoid
making later as a result ;)
<masak> I'd appreciate that. :)

Finally, here are the links to those CPAN modules that were mentioned:

Path::Dispatcher
<http://search.cpan.org/~sartak/Path-Dispatcher-0.09/lib/Path/Dispatcher.pm>
MooseX::Object::Pluggable
<http://search.cpan.org/~groditi/MooseX-Object-Pluggable-0.0009/lib/MooseX/Object/Pluggable.pm>
HTTP::Engine
<http://search.cpan.org/~yappo/HTTP-Engine-0.1.4/lib/HTTP/Engine.pm>
CGI::Application
<http://search.cpan.org/~markstos/CGI-Application-4.21/lib/CGI/Application.pm>

I'm still playing with SVN to get a pre-5.50 version of the dispatcher
from <http://dev.catalyst.perl.org/repos/Catalyst>. I might write
again when I've extracted it.

// Carl

[Carl Mäsak]

Carl (>):

> I'm still playing with SVN to get a pre-5.50 version of the dispatcher
> from <http://dev.catalyst.perl.org/repos/Catalyst>. I might write
> again when I've extracted it.

Shown here.

<http://gist.github.com/73875>

I still don't know what the actual mistake consisted of, mind you. :)
I hope to find out by comparing the old and the new ones, and
discussing it on #catalyst.

// Carl

[Илья]

Hi there,

>> <ruoso> make everything a variation of :Chained

I like this. We use Catalyst a lot, and when we fully understood
:Chained it makes our controllers clearer and our dreams quite.

thinking aloud:

class Company {
method chain_start ($company_id) { ... }
method show ($id) { ... }
}

class Offer {
multi method index { ... }
multi method index ($company_id) { ... }
}

GET /company/*
call Company.show($id) and show one company

GET /company/*/offer
call chain_start, then call Offer.index($company_id) and show offers
of this company

'show' and 'index' works because of REST, mb 'does REST' in classes definition

Ilya

[Илья]

Hi there,

http://sial.org/pbot/35421
link on the ruoso scetch

see
http://irclog.perlgeek.de/november-wiki/2009-03-09
for comments

Ilya

[Carl Mäsak]

Илья (>):

> http://sial.org/pbot/35421
> link on the ruoso scetch

A later version of that paste also exists in the Web.pm repo, at this location.

<http://github.com/masak/web/blob/master/doc/web-framework-roles>

// Carl

[Daniel Ruoso]

Additionally, follows a conversation I had yesterday with mst on
#catalyst-dev

<ruoso> For those aware of the Web.pm TPF grant, I sketched some ideas
on my suggestions for masak to implement... http://sial.org/pbot/35421
it is 100% based on Catalyst, but with the dispatcher simplified to just
chained actions and using some Perl 6 features like $obj.*method
<ruoso> I have to say that while I simplified to support only Chained
actions, each part of the chain is then allowed to use whatever it
pleases to match its part...
<mst> ruoso: I've been talking to ... masak?
<ruoso> yes... he's the grantee
<ruoso> mst, I'm trying to brainstorm ideas to him, to take him to the
most abstract level as possible
<mst> I don't honestly think you need private actions
<mst> the begin/auto/end stuff I barely use with Chained
<mst> except for the end action to render the view
<mst> I suspect a more effective approach is instead of having
<mst> $action_1->call, $action_2->call
<mst> is to call $action_1
<mst> and let it invoke $action_2 when it's ready
<mst> so then you can just call render at the end of your base action
<ruoso> mst, that's what I've planned
<ruoso> it get's the outermost action
<mst> then you don't need begin/auto/end
<mst> also, look at Sartak's Path::Dispatcher
<ruoso> mst, I already don't have an "auto"
<ruoso> but I suppose begin and end might be usefull
<ruoso> but I already moved it to the action itself
<ruoso> it's not a separated dispatch
<ruoso> it just calls begin, then execute, then end
<ruoso> so if the action is chained
<ruoso> it will call the begin in the whole chain
<mst> begin and end are pointless for this
<mst> if action1 calls action2
<mst> you can provide an action1 base class that does 'em anyway
<mst> like the catalyst _DISPATCH action
<ruoso> right... I actually didn't want to rip it off...
<ruoso> but have no strong opinion
<mst> I'm saying "don't bother with the extra complexity since you can
add it back in later if you need it"
<ruoso> right... that can be composed into some action that want begin
and end
<ruoso> mst, my idea of private actions was just to allow "detach" to
something non-chained
<mst> I don't think forward or detach are worth it either
<mst> just have a DetachException
<ruoso> yes yes yes
<mst> $controller.method; throw DetachException;
<ruoso> detach will actually raise a ControlExceptionDetach
<mst> where did we need a private action?
<ruoso> since Perl 6 has ControlExceptions and Failures
<ruoso> the first handled by CONTROL blocks, while the other handled by
CATCH block
<ruoso> mst, I like to think of /error404 as private, most of the time
<ruoso> btw, default died as well, since I added a $.priority to the
public actions...
<ruoso> so you can add an action that matches whatever with the lower
priority
<mst> default is already dead
<mst> as is index
<mst> we recommend you use :Path for them anyway
<mst> I tend to anchor /error404 as a catch-all at /
<mst> but I still don't see why it needs to be an action
<mst> just add throw DetachException; at the bottom of it
<mst> $c.controller('Root').error_404;
<ruoso> eventually you want to do something there, like "did you mean
something else?"
<ruoso> and present suggestions
<mst> though, actually, I don't think you need to detach to 404 at all,
normally
<mst> better is to verify the URL as you match the dispatch
<mst> which we can't do yet but I'd like to add
<ruoso> mst, I actually considered writing the whole dispatching as a
grammar
<ruoso> but in the end, I think having those as separated steps is not
that all bad
<ruoso> it's very problematic with the several dispatchtypes
<ruoso> where it's hard to figure out what is going to happen
<ruoso> but once you have a plain ordered list of possible matches
<ruoso> I think it's pretty straightforward
<ruoso> mst, after thinking about it a bit more, the chained dispatch
will be built using regular Perl 6 regexes, that allows you to run
arbitrary code during the match
<ruoso> so, at init, it will compile a grammar for every public action,
which could potentially include checks for "does this post exist?"
during match
<mst> if you built a single grammar that could work
<mst> I sort of thought what you really wanted was multis
<mst> so you split the path on /
<mst> and then multi the path parts
<mst> method ('domain', DomainNameStr $domain :does(Coerce), InnerMatch
\@inner) {
<ruoso> http://sial.org/pbot/35424
<ruoso> mst, it builds regexes and uses the captures as arguments...
while just passing around for execute
<ruoso> so, it builds a bottom-up grammar for the action
<ruoso> where the token for the action can use positional and named
captures
<ruoso> that will be the arguments sent to the block being executed
* dhoss saiu (Ping timeout: 360 seconds)
<ruoso> mst, http://sial.org/pbot/35426 contains the sketches now
supporting arbitrary regex with chained being compiled once to a single
regex that return the action and the capture for "execute"
<ruoso> which, in Perl 6, means that you can embbed checking "does this
post exist" in the dispatching...
<mst> I still think multimethod style would be more elegant
<ruoso> even with the regex thing?
<mst> I think this is messy.
<mst> I think you're using grammars because you can.
<mst> I also think that makes you -very- path-oriented
<ruoso> hmmm...
<ruoso> maybe I'm not quite seeing how would your multimethod style work
then
<ruoso> but I'm doing it quite URL oriented, yes...
<ruoso> mst, which sense of being "path oriented" you want to avoid?
<mst> things like the HTTP method and the message body type should be
able to take part in dispatch
<ruoso> hmm... I see...
<mst> also thre query string
<mst> that's the most important one
<ruoso> well, I don't know if this is a dirty solution... but you can
run arbitrary assertions in regexes...
<ruoso> it is not really just about strings...
<ruoso> and at that point, the $*request context variable is already
available
<mst> by having a context, you're already wrong
<mst> the app should be $response = $app->handle($request)
<ruoso> right
<ruoso> I don't have a "$c", if that's what you mean
<ruoso> I have "contextual variables"
<ruoso> which is something different...
<mst> dynamic scope?
<ruoso> yes
<ruoso> so inside method handle
<ruoso> it defines "my $request is context"
<ruoso> and something probably should define "my %stash is context"
somewhere as well
<mst> I don't think you want a stash either
<mst> damn, the sketches I had are on my laptop, not here
<mst> can we chat tomorrow?
<mst> pref. with masak present
<ruoso> yes... sure... are you on freenode also?
<mst> oh, actually, hell, I'm traveling tomorrow
<mst> so it'd be wed
<mst> erm, I help run freenode #perl
<ruoso> wed I have a lecture to give
<ruoso> ok... so the discussions for this grant are taking place in
#november-wiki
<ruoso> at freenode
<mst> but I'm usually only on #perl6 to piss larry off because I've
broken his code again
<mst> it's nice to see it all on freenode though
<mst> giving off a clear signal that perl6 isn't really perl is
definitely a good thing
<mst> (brb)

daniel

[Илья]

Hi,
thank you, interesting to read.

I think dispatcher should by natural and use perl6 MMD. In perl6 we
have so strong infrastructure, we should use it, instead of create
another world on top of it.

Ilya



I think we should keep dispatcher

2009/3/10 Daniel Ruoso <dan...@ruoso.com>:

[Daniel Ruoso]

Em Ter, 2009-03-10 às 22:04 +1000, Илья escreveu:
> I think dispatcher should by natural and use perl6 MMD. In perl6 we
> have so strong infrastructure, we should use it, instead of create
> another world on top of it.

I'm actually failing to see how that would work, could you sketch some
ideas?

daniel

[Carl Mäsak]

Илья (>):

> I think dispatcher should by natural and use perl6 MMD. In perl6 we
> have so strong infrastructure, we should use it, instead of create
> another world on top of it.

Indeed. The one who creates a dispatcher on top of Perl 6's MMD wins,
I think. The advantages are just so great.

I'm very happy the way the discussion has taken off here on the list,
and on various channels. It's increasingly clear that the help from
people outside our group of three is not only very welcome, but
actually needed in order to produce a usable web toolkit. Keep up the
good work, everybody.

// Carl

[Илья]

> I'm actually failing to see how that would work, could you sketch some
> ideas?

I still have big mess in my head, and just trying to find reasonable
things for me in RoR, Catalyst, Waves, Jifty etc.
So this sentence -- how I fell component of the right way, now.

We can express resource as set of multies:

multi method res ($method where "GET") { ... } # index
multi method res ($method where "GET", $id) { ... } # show
multi method res ($method where "PUT", $id ) { ... } # update
multi method res ($method where "DELETE", $id) { ... } # delete
...

or class is resource, but methods is HTTP methods:

class res is Resource {
method GET { ... } # index
method GET ($id) { ... } # show
method GET ($id, $act where 'new') # form for new
method POST { ... } # create
...
}

Ilya

[Илья]

>    method GET { ... } # index
>    method GET ($id) { ... } # show
>    method GET ($id, $act where 'new') # form for new

^ multi

chained, rewriting of my previous sketch in "discussion with mst on
#catalyst" thread:

class Company is Resource {
multi method GET { ... } # index
multi method GET ($id) { ... } # show
multi method Chain ($id, $issue where {$_ ~~ Offer}) { ...
$issue.Chain($id) }
multi method Chain ($id, $issue where {$_ ~~ Account}) { ...
$issue.Chain($id) }
}

class Offer {
method Chain ($id) { ... }
}

GET /company/*
call Company.GET($id) and show one company

GET /company/*/offer
call Company Chain ($id, Offer.new()), show company offers by id

Please, do not throw big rocks into my, it is just sketch and I m.b.
miss a lot of important things.

[Moritz Lenz]

Hi,

Carl Mäsak wrote:
> Илья (>):
>> I think dispatcher should by natural and use perl6 MMD. In perl6 we
>> have so strong infrastructure, we should use it, instead of create
>> another world on top of it.
>
> Indeed. The one who creates a dispatcher on top of Perl 6's MMD wins,
> I think. The advantages are just so great.

Indeed. It means that we have to have some a way to split URLs into a
form where they participate in MMD. And that immediately means that we
can have a very simple and customizable dispatcher.

The default splitter will probably do something very simple: it
decomposes the URL

/foo/bar/baz?a=b&c=d

Into the positional arguments <foo bar baz> and the named arguments
:a<b>, :c<d>. It uses that capture to do MMD. Nice and simple.

But for more complex URL layouts you can write a different splitter.
Suppose you want to have separate subsystems, say a blog, a wiki and a
smurf. Then you write your own splitter that does nothing:

sub split-url(Str $url) { $url }

and one multi sub that accepts a single positional:

# assuming leading '/' is stripped
multi sub dispatch(Str $url) {
my ($subsystem, $rest) = $url.split(2);
dispatch(lc $subsystem, $rest);
}

And each subsystem then declares its own dispatch routine:

multi sub dispatch(Str $subsystem where 'smurf', Str $rest) {
Smurf.new.dispatch($rest);
}
multi sub dispatch(Str $subsystem where 'blog', Str $rest) {
# other sub-dispatch here
}

The nice things about this scheme is that it
* offers a good default for small projects
* offers great flexibility for more involved projects
* heavily relies on the multi dispatcher to do all the hard work

I think that's the kind of "unopionated" dispatch we're looking for -
sane defaults, little effort, great flexibility.

The one disadvantage I see is that each subsystem has to place a method
into the parent's namespace (which is, strictly speaking, monkey
patching), or the parent has to know about its childs.

Cheers,
Moritz

--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/

[Daniel Ruoso]

Em Ter, 2009-03-10 às 20:23 +0100, Moritz Lenz escreveu:
> The default splitter will probably do something very simple: it
> decomposes the URL
> /foo/bar/baz?a=b&c=d
> Into the positional arguments <foo bar baz> and the named arguments
> :a<b>, :c<d>. It uses that capture to do MMD. Nice and simple.

This looks very much Ok, but chained actions seems to become very less
interesting...

/blog/myblog/category/foo/post/bar

would require

multi GET ('blog', $blogname) {
# load information related to $blogname
}
multi GET ('blog', $blogname, 'category', $category {
GET('blog', $blogname);
# load information related to $category
}
multi GET ('blog', $blogname, 'category', $category, 'post', $bar) {
GET('blog', $blogname, 'category', $category)
# load information related to this post
}

which doesn't look very pretty

daniel

[Moritz Lenz]

That's right, I do see that it won't replace a chained dispatcher.
But it's dead simple to plug one in, once somebody has written one
(which I'll happily leave to you, since I know you're better at it than
I am).

And it would be nice if Web.pm shipped with such a chained dispatcher,
so that plugging it in is a matter of one line of code.

[Carl Mäsak]

Moritz (>), Daniel (>>), Moritz (>>>):

>>> The default splitter will probably do something very simple: it
>>> decomposes the URL
>>>      /foo/bar/baz?a=b&c=d
>>> Into the positional arguments <foo bar baz> and the named arguments
>>> :a<b>, :c<d>. It uses that capture to do MMD. Nice and simple.
>>
>> This looks very much Ok, but chained actions seems to become very less
>> interesting...
>>
>>   /blog/myblog/category/foo/post/bar
>>
>> would require
>>
>>   multi GET ('blog', $blogname) {
>>      # load information related to $blogname
>>   }
>>   multi GET ('blog', $blogname, 'category', $category {
>>      GET('blog', $blogname);
>>      # load information related to $category
>>   }
>>   multi GET ('blog', $blogname, 'category', $category, 'post', $bar) {
>>      GET('blog', $blogname, 'category', $category)
>>      # load information related to this post
>>   }
>>
>> which doesn't look very pretty
>
> That's right, I do see that it won't replace a chained dispatcher.
> But it's dead simple to plug one in, once somebody has written one
> (which I'll happily leave to you, since I know you're better at it than
> I am).
>
> And it would be nice if Web.pm shipped with such a chained dispatcher,
> so that plugging it in is a matter of one line of code.

Let me try, by the tried and true method of "repeating what the other
one said", to see if I understand you:

* Default URI dispatch could work through the multi-method dispatch
(MMD) of Perl 6.

* This is good, because instead of reinventing a moderately complex
ruleset, we just gear into one that's already there. 'sides, seasoned
Perl 6 users are already familiar with it.

* This scheme doesn't work very well with the chained type of
dispatch. (Other discussions tell me that this type of dispatch is
often very attractive in a web framework.)

* Thus, there's a need for a module (or similar) that facilitated
chained dispatch with the above scheme. That is, it would encapsulate
the MMD dispatch and provide a nice chained-dispatch API, while
hopefully still retaining many of the benefits of using the former.

Did I get that somewhat right? :)

// Carl

[Илья]

Hi there,
just another one idea to this stash. We can use named arguments for checks:

class Account is HTTP::Resource {
multi method GET ($id, :$user_role where "admin" ) {...}
}

Ilya

2009/3/11 Moritz Lenz <morit...@gmail.com>:

[Daniel Ruoso]

Em Qui, 2009-03-12 às 09:24 +0100, Carl Mäsak escreveu:
> Let me try, by the tried and true method of "repeating what the other
> one said", to see if I understand you:

> * This scheme doesn't work very well with the chained type of
> dispatch. (Other discussions tell me that this type of dispatch is
> often very attractive in a web framework.)

Not just "very attractive", but it's actually the way people work most
of the time (at least the non-begginer Catalyst users)

> * Thus, there's a need for a module (or similar) that facilitated
> chained dispatch with the above scheme. That is, it would encapsulate
> the MMD dispatch and provide a nice chained-dispatch API, while
> hopefully still retaining many of the benefits of using the former.

After sending this mail, there was an interesting development about this
issue in #november-wiki[1]. Basically:

my @parts = $*application.path-parts($*request);
@parts.reduce: &action_execute;

Where, for

GET /blog/myblog/category/foo/submit-post

we would get a list composed of

Path::Root('/'), 'blog', 'myblog', 'category',
'foo', 'submit-post', Request::Method('POST')

and the folowing multi definitions

our multi action_execute(Path::Root $r, 'blog', $blogname) {
# load blog-specific data
return Chained('/blog/*');
}
our multi action_execute(Chained $foo where '/blog/*',
'category', $categoryname) {
# load category-specific data
return Chained('/blog/*/category/*');
}
our multi action_execute(Chained $foo where '/blog/*/category/*',
'submit-post', RequestMethod $m where 'POST') {
# create the new post in that category of that blog.
}

By a coincidence, all the multis here got three arguments, but it should
be able to work with multis with different arity.

We would still need to work out ways for it to still support for Actions
to be regular objects that can be composed by other roles, so we can
have action classes like Catalyst::Action::SOAP::DocumentLiteral

But maybe that just mean that the only change is how the actions are
declared, where the multi being executed is simply a proxy to actually
invoke the action...

daniel

[Илья]

>We can use named arguments for checks:
>
> class Account is HTTP::Resource {
>    multi method GET ($id, :$user_role where "admin" ) {...}
> }

ah, I missed:
Perl 6.0.0 is not required to support multiple dispatch on named parameters,
only on positional parameters. Note that most builtins will map known
named parameters to positional via a C<proto> declaration.

So we should use proto to make that`s happend, but proto newer called
if we have multi method with () signature.
To be sync with Rakudo I make drafts/Res.pm to touch simple working
example related to our topic.

Ilya

[Илья]

Hi there,

One problem with chained and MMD-based dispatcher is how to know arity of calls.
The simplest approach is to use an agreement, like:

/resource1/$id/resource2/$id/resouce3...

It is possible if we throw out verbs and second noun from the URI.

GET /resource # idex
GET /resource/$id # show
PUT /resource/$id without data # show update form
PUT /resource/$id with data # update
POST /resource without data # show create form
POST /resource with data # create
DELETE /resouce/$id # delete

Any other action, like 'verify', 'move', 'turn' could be done by
POST/$id and data.
I see that as a clear REST, but it looks like I'm missing something.
I hope someone who know why people still use 'new' and 'edit' noun in
other f/w when implementing REST can explain me that point.

So with this agreement we have very strict application API and chained
action will be simple to implement.
But we have a lot of limitations, too.

***

> our multi action_execute(Path::Root $r, 'blog', $blogname) {
> # load blog-specific data
> return Chained('/blog/*');
> }

<...>

> By a coincidence, all the multis here got three arguments, but it should
> be able to work with multis with different arity.

But what should I do if I want to have /blog/* as blog show, not the
beginning of the Chain?

How does dispatcher find out arity? Does it try each possibilities
starting from biggest arity?

> We would still need to work out ways for it to still support for Actions
> to be regular objects that can be composed by other roles, so we can
> have action classes like Catalyst::Action::SOAP::DocumentLiteral

I am going to read its pod.

Actions as objects seems to be expensive.

Ilya
Ilya

[Moritz Lenz]

s/somewhat/completely/ ;-)

[Daniel Ruoso]

Em Sex, 2009-03-13 às 00:59 +1000, Илья escreveu:
> One problem with chained and MMD-based dispatcher is how to know arity of calls.
> The simplest approach is to use an agreement, like:

The trick is not requiring them to have the same arity. Reduce would
consume as many items as each candidate that matched that specific
iteration.

> /resource1/$id/resource2/$id/resouce3...
> It is possible if we throw out verbs and second noun from the URI.

> I see that as a clear REST, but it looks like I'm missing something.
> I hope someone who know why people still use 'new' and 'edit' noun in
> other f/w when implementing REST can explain me that point.

But remember that not all applications are REST, so yes, that can be
done, but no, that can't be a requirement.

> > our multi action_execute(Path::Root $r, 'blog', $blogname) {
> > # load blog-specific data
> > return Chained('/blog/*');
> > }
> <...>
> > By a coincidence, all the multis here got three arguments, but it should
> > be able to work with multis with different arity.
> But what should I do if I want to have /blog/* as blog show, not the
> beginning of the Chain?

You probably didn't notice Path::Root in the beggining and
Request::Method in the end. This would be how to tie an action to the
start or the end or the path.

> How does dispatcher find out arity? Does it try each possibilities
> starting from biggest arity?

It will proceed as normal dispatch, but somehow it must support do a
partial matching, and telling how many have matched. That's all.

> Actions as objects seems to be expensive.

"All evil is premature optimization squared."

daniel

[Илья]

Hi Daniel!

First of all, please, sorry for my English.

I feel I need to explain my vision. Please, note this is my current
vision, we are working to find better one.

Daniel (>):

> The trick is not requiring them to have the same arity. Reduce would
> consume as many items as each candidate that matched that specific
> iteration.

Yes. But I am trying to make very simple model, where all dispatcher
work is to call method, and it does not know a lot about actions
(resources in my draft). Maybe this is superfluous simplification. I
am biting on the naive implementation, just to find out how this idea
can work for us. I will pull it when it starts to work properly with
chained resources. I hope I'll do it tomorrow.

I like Moritz++ idea about very simple transformation URI to the call.
This is good for masak`s PLAN Aleph. I like idea to make dispatcher
pluggable, app-specific, not f/w-specific. (If I understand right this
is part of Moritz`s vision too.) In this case we can combine
applications with different architecture.

I like REST, and will create RESTfull dispatcher. I will use it in
Maya. So it is good idea to make web applications pluggable (like in
Django f/w), because a lot of web projects need blog or forum as a
part. Developer can prefer another architecture in its own app, but
can add Maya as a part with its own dispatcher.

Daniel (>):
> in Catalyst the "Request" object is very HTTP-specific
> this is something that can be fixed

In general I like this idea. But this is about applications in
general... we are making web framework. In my vision Web.pm should be
HTTP-specific f/w.

Our grant goal is to create lightweight web f/w. I looked on your
sketches closley, and saw very-very flexible path-oriented application
organization.This flexability looks good, and I like it, but this is
absolutely needless for simple and mid-level web applications. So I
wondering do we really need all this stuff?

I was working with Catalyst and after it with RoR. Rails f/w does not
give you freedom, like Catalyst does, but has a lot of rules and
agreements. Rails f/w is successful because it is the tool for one
task, and I think we should go at this direction.

Rails have simple conception of dispatch with Routines, it is very
useful. With routines your dispatch map is in one place. You can use
different level of accuracy in declaration: you can say what should be
exactly called on specific path, or you can use pattern to say where
app should find actions. In Rails REST is implemented on top of this
system.

Grammatic-based dispatcher looks like a good idea. I think we should
sketch it. Regexes can be noisily, but with grammar inheritance we can
create some sort of DSL for this dispatcher. It will be wonderful if
we find how to make it working on different levels, like Routines.

Ilya (>>), Daniel (>):

>> But what should I do if I want to have /blog/* as blog show, not the
>> beginning of the Chain?
>
> You probably didn't notice Path::Root in the beggining and
> Request::Method in the end. This would be how to tie an action to the
> start or the end or the path.

No I see that, but still do not understand how dispatcher should know
what to call. Mb this is because I am still thinking about simple
dispatcher which does not know anything about this methods and its
signature.

>> Actions as objects seems to be expensive.
>
> "All evil is premature optimization squared."

This mantra is not so good for me in this situation. KISS is better :)
I newer work with SOAP, mb this is the point.

Ilya

[Daniel Ruoso]

Em Dom, 2009-03-15 às 01:09 +1000, Илья escreveu:
> > You probably didn't notice Path::Root in the beggining and
> > Request::Method in the end. This would be how to tie an action to the
> > start or the end or the path.
> No I see that, but still do not understand how dispatcher should know
> what to call. Mb this is because I am still thinking about simple
> dispatcher which does not know anything about this methods and its
> signature.

my @parts = some-splitter-function();
@parts.reduce: &multi;

[Daniel Ruoso]

sorry, I hit send before writing the message...

the idea here is that Perl 6 itself would do the dispatch through
reduce... This was when I started liking the multi-dispatch idea.

daniel

[Timothy S. Nelson]

On Sun, 15 Mar 2009, ???? wrote:

> Our grant goal is to create lightweight web f/w. I looked on your
> sketches closley, and saw very-very flexible path-oriented application
> organization.This flexability looks good, and I like it, but this is
> absolutely needless for simple and mid-level web applications. So I
> wondering do we really need all this stuff?

I think if a package is really to deserve the name "Web", rather than
something more like "LWF" (lightweight web framework), it should attempt to be
as perlish a web framework as possible. To me, that means (among other
things) "Easy things easy, hard things possible". I'm not saying to write
everything now that will make hard things possible, but simply to at least
leave room for others to do so.

> I was working with Catalyst and after it with RoR. Rails f/w does not
> give you freedom, like Catalyst does, but has a lot of rules and
> agreements. Rails f/w is successful because it is the tool for one
> task, and I think we should go at this direction.

I think Web should be the base packages for something that is a
single tool for the task. Think of it being something like "Rails on
Catalyst" -- Web should be the basic part, and the Rails part should have a
less generic name, so that people can search for it properly (I mean, do we
really need beginniners Googling "Web", and not finding anything relevant to
what we're doing here?)

Anyway, HTH. I had these thoughts days ago, but I've been abed sick,
so didn't get them down until now.

http://en.wiktionary.org/wiki/abed

:)

---------------------------------------------------------------------
| Name: Tim Nelson | Because the Creator is, |
| E-mail: way...@wayland.id.au | I am |
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----

[ab5tract]

Hey all, just lurking and wondering how Web.pm is going these days.
Also, wanted to propose the name 'Feather' for the purpose of
disambiguation that Timothy described.

> | E-mail: wayl...@wayland.id.au    | I am                           |