On Tue, Sep 18, 2012 at 12:19:46PM -0500, Bill Stephenson wrote:
> On Sep 15, 2012, at 10:58 AM, Mark Stosberg wrote:
>
> > Most web clients support JSON now, which allows for more complex
> > structures than the simple key/value pair that CGI.pm uses.
>
>
> Mark, I think this is relevant to wha
On Sep 15, 2012, at 10:58 AM, Mark Stosberg wrote:
> Most web clients support JSON now, which allows for more complex
> structures than the simple key/value pair that CGI.pm uses.
Mark, I think this is relevant to what I'm advocating here.
That JSON support is accomplished with javascript pars
On 09/15/2012 05:00 PM, Jiří Pavlovský wrote:
> On 15.9.2012 3:22, Mark Stosberg wrote:
>> Regarding performance, I recently benchmarked accessor generation time
>> for Moo vs Mouse vs Moose vs manual accessors (what CGI::App uses) and
>> raw hashes. In a persistent environment like you are using
On 15.9.2012 3:22, Mark Stosberg wrote:
> Regarding performance, I recently benchmarked accessor generation time
> for Moo vs Mouse vs Moose vs manual accessors (what CGI::App uses) and
> raw hashes. In a persistent environment like you are using Moose was
> generating 162,999 accessers *per sec
On Sep 15, 2012, at 10:41 AM, Mark Stosberg wrote:
> I stated to look at the code, but I didn't get very far until I ran into
> this notice:
>
> # Do not read, copy, distribute, execute, run, or use
> # this code without express written permission from
> # William H. Stephenson.
>
> At that poi
>
> I know that you're right according to common practice, so I have to
> admit it made me laugh reading that this morning for that very reason.
>
> But... in my (weak) defense, in chapter three, page 119, of Lincoln's
> book, "The official guide to programming with CGI.pm" is the "Advanced
> Tric
Bill--
> I've sort of taken my own path to create web apps, and while it works for me,
> I've gotten some blowback for it a few times over the years, but I really
> don't mind that, so I'll explain it.
>
> I have a small demo "Note Pad" app at www.raspberryperl.com:
>
> app -> http://r
>> I would generally plan to keep the core small, but would welcome more
>> full-featured stacks to be shipped that were based on it, as Titanium
>> did for CGI::Application.
>
> My motivation for this is based on our needs. We use CAP to write not
> just authenticated applications, but those with
On Sep 13, 2012, at 12:02 PM, Jerry Kaidor wrote:
>> Hi Bill,
>>
>> This is fascinating, but I think you're abusing CGI.pm for something
>> it was never intended for.
>
> *** Which is one of the glories of open source. Things keep getting used
> for stuff that the original writers never envisi
> Hi Bill,
>
> This is fascinating, but I think you're abusing CGI.pm for something
> it was never intended for.
*** Which is one of the glories of open source. Things keep getting used
for stuff that the original writers never envisioned.
- Jerry Kaidor
# CGI::Applic
Hi Bill,
This is fascinating, but I think you're abusing CGI.pm for something
it was never intended for.
How about using XML::Simple to encode the data and write that into the
flat files?
# Grab a hashref of data from the posted form
my $data = $cgi->Vars;
# Dump data into file
XMLout($data, Ou
> There not yet specific plans for how CGI.pm will be replaced. How do you
> use the save/restore feature?
Thank you, Mark. I appreciate your taking my concerns under consideration.
I've sort of taken my own path to create web apps, and while it works for me,
I've gotten some blowback for it a
Hi Brett
On 11/09/12 00:05, B. Estrade wrote:
> I think what I was thinking of for a "more developed" plugin system is
> to provide a way to better manage when plugins are fired wrt hooks.
>
> For example, have an "after" or "before" type of modifier when
> registering a callback would be nice.
Thank you, Mark.
I accept what you so at face value and will seek to educate myself
more. Below I address the questions you asked me.
On Sat, Sep 08, 2012 at 06:10:55PM -0400, Mark Stosberg wrote:
>
snip..
> >
> > It would be really nice to merge in some bare bones Authentication and
> > Autho
Bill,
Thanks for feedback. Responses are below.
On 09/02/2012 01:46 PM, Bill Stephenson wrote:
> Hi Mark,
>
> Nice to hear you're going to move forward with the CAP project.
>
> After reading your comments about CGI.pm, and comments from others
> here, I'm left wondering about a few things. If
Hi Mark
On 09/09/12 10:28, Mark Stosberg wrote:
>
- Uses Any::Moose / Mouse. I endorse the Moose API and Mouse brings
much of that API to lower resource environments, like the CGI
environment where CGI::Application has always performed well.
>>
>> This is tricky. Why is
>>> - Uses Any::Moose / Mouse. I endorse the Moose API and Mouse brings
>>> much of that API to lower resource environments, like the CGI
>>> environment where CGI::Application has always performed well.
>
> This is tricky. Why is the env low-resourced? And if it is, what's wrong
> with
Brett,
Thanks for the feedback.
>> - A "::Compat" addition that allows people to keep using a maximal
>> amount of the old API if they need to. (Including a certain amount of
>> plugins)
>
> Or maybe just do something like how perl5 turns on new version based
> features (e.g., use CGI::A
Richard,
Thanks for the feedback.
> But since C::A first appeared we now have newer frameworks like
> Catalyst, Mojo, and the more recent Dancer (also in the process of
> being rewritten to embrace the Moose API). Given that Ron has already
> forked C::A I wonder if there is any point embarking
Thank you, Rhesa. This is helpful.
My last common on cgiapp_init and setup will be this. It's not simply
how deeply inheritance can be, it's the fact that there are 2 explicit
API methods for initializing an instance beyond what is provided for
in the ancestor. For me, it'd make more sense to do
Hi Brett
On 07/09/12 00:48, B. Estrade wrote:
> What I mean is that there are 2 methods that basically do the same
> thing. If you have MyApp (ISA CGI::Application), you would initialize
> runmodes and whatnot via cgiapp_init. Say you subclass MyApp to get
> MyApp::Foo, but want to keep what is
On 09/06/2012 04:48 PM, B. Estrade wrote:
> You're limited to 2 generations below CAP if you want to subclass
> without explicitly calling on SUPER because you have 2 explicit
> methods -cgiapp_init and setup. I am suggesting a way to provide any
> number of generations without having to call on
Snipped
On Thu, Sep 06, 2012 at 09:12:40AM +1000, Ron Savage wrote:
> Hi Brett
> > It would be really nice to merge in some bare bones Authentication and
> > Authorization support - maybe ever by more fully developing CAP's lifecycle.
>
> Likewise. It's a pity a standard(!) way of doing this with
Hi Brett
I'm snipping this email because I expect to pen several replies.
On 06/09/12 03:57, B. Estrade wrote:
> Thank you, Mark. Responses are inlined.
>> - A "::Compat" addition that allows people to keep using a maximal
>> amount of the old API if they need to. (Including a certain amount
Thank you, Mark. Responses are inlined.
On Tue, Aug 28, 2012 at 11:27:04PM -0400, Mark Stosberg wrote:
>
> Hello Everyone.
>
> I'll start with a apology about not being as present as I intended.
> Messages from this list were not coming directly to my Inbox for some
> time, and it took me longe
Hi Mark,
I also use C::A everyday - my main application that I wrote and maintain
is a C::A. You are of course right that C::A uses some out-of-date
procedures like the query method. But since C::A first appeared we now
have newer frameworks like Catalyst, Mojo, and the more recent Dancer
(als
On 08/28/2012 11:27 PM, Mark Stosberg wrote:
> I look forward to being conversation with you all more about this. I'll
> set a goal to release the first code-as-draft for my proposal within a
> week, and look forward to your feedback to sculpt it into a releasable
> form.
I agree with just about
>> I started writing my own fork over a year ago in hopes of having
>> something to share around the time for YAPC 2011. While I needed to put
>> that on hold for a while, It's now on the verge of the initial release.
>
>> Here are the key points I have mind for the update I'll be publishing
>> s
On 29.8.2012 8:26, Gabor Szabo wrote:
> I started writing my own fork over a year ago in hopes of having
> something to share around the time for YAPC 2011. While I needed to put
> that on hold for a while, It's now on the verge of the initial release.
>> Here are the key points I have mind for the
On Wed, Aug 29, 2012 at 6:27 AM, Mark Stosberg wrote:
> I'll start with a apology about not being as present as I intended.
No need for that.
> I started writing my own fork over a year ago in hopes of having
> something to share around the time for YAPC 2011. While I needed to put
> that on ho
Hello Everyone.
I'll start with a apology about not being as present as I intended.
Messages from this list were not coming directly to my Inbox for some
time, and it took me longer than I wanted to get that addressed.
Starting today, messages should be going back in my Inbox again, and I
will at
31 matches
Mail list logo
