You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Massimo Manghi <mx...@apache.org> on 2014/12/13 11:50:31 UTC
Fwd: Hi. A suggestion.
Rani Ahmad gave me permission to forward to rivet-dev his proposal for an
alternate way to force redirection to a different URL using the <meta ....>
tag. Rani claims this approach could attain the same effect while
preventing the scripts from failing with the "headers already sent" error.
It still makes sense that a script which could issue a redirect has in
principle to determine whether to divert to a different URL *before* any
output is sent to the channel. admittedly this is rigid because forces a
certain design (though a sane one), it's largely undocumented and in the
end there should be a better more flexible way to do this
We obtain redirection with the 301 HTTP code and when the headers command
is called the code checks for the headers_sent flag
TCL_CMD_HEADER( Rivet_Headers )
{
...
if (globals->req->headers_printed != 0)
{
Tcl_AddObjErrorInfo(interp ,"Cannot manipulate headers - already
sent", -1);
return TCL_ERROR;
}
globals->req->headers_printed is set when the Rivet channel output
procedure is called by Tcl I/O subsystem and I wonder if there are
different ways to do it, for example making the channel implementation more
flexible about buffering. Of course this doesn't rule out the possibility
of exploiting other ways (like in Rani's proposal), but it seems to me the
HTTP protocol has to be supported in the best possible way
-- Massimo
---------- Forwarded message ----------
From: Rani Ahmed <ra...@gmail.com>
Date: Thu, Dec 11, 2014 at 8:37 PM
Subject: Hi. A suggestion.
To: Massimo Manghi <mx...@apache.org>
Hi Massimo.
Well I suggest that you add a better redirect function/procedure other
than the *[headers* redirect $url *]* . This one always makes many people
go into the annoying error message of
*headers already sent .*
The procedur*e* will be the following, I found it on Stackoverflow. I
understand that I can put it for my own, but this little thing - I think -
can be the key that makes Rivet attractive.
*proc* http_redirect *{* url *} {*
*?>* <meta http-equiv="refresh" content="0;url='*<?=*$url;*?>*'">
*<?*
*}*
Re: Hi. A suggestion.
Posted by Massimo Manghi <ma...@unipr.it>.
sustained!
-- M
On 12/15/2014 10:21 PM, Damon Courtney wrote:
> Well, it’s a new command, so I would suggest changing it. I find that
> in most cases of a modern web app, you’re doing a temporary redirect,
> not a permanent. 301 was really messing me up because the browser
> would cache it, and then I’d have to blow away my cache to make
> things work again.
>
d
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Damon Courtney <da...@tclhome.com>.
Well, it’s a new command, so I would suggest changing it. I find that in most cases of a modern web app, you’re doing a temporary redirect, not a permanent. 301 was really messing me up because the browser would cache it, and then I’d have to blow away my cache to make things work again.
So, I would humbly suggest we leave that command just like it is. The [headers redirect] can keep the same semantics for backward compatibility.
> On Dec 15, 2014, at 3:13 PM, Massimo Manghi <mx...@apache.org> wrote:
>
> The 301 (http://en.wikipedia.org/wiki/HTTP_301) is the permanent
> redirection so, in order to keep the 'permanent' semantics consistent,
> the default must be 1
>
> -- Massimo
>
> On 12/15/2014 06:51 PM, Damon Courtney wrote:
>
>> proc ::rivet::redirect {url {permanent 0}} {
>> no_body ; ## don’t output anything on a redirect
>> headers set Location $url
>> headers numeric [expr {$permanent ? "301" : "302"}]
>> abort_page ; ## stop any further processing
>> }
>>
>> Damon
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Massimo Manghi <mx...@apache.org>.
The 301 (http://en.wikipedia.org/wiki/HTTP_301) is the permanent
redirection so, in order to keep the 'permanent' semantics consistent,
the default must be 1
-- Massimo
On 12/15/2014 06:51 PM, Damon Courtney wrote:
> proc ::rivet::redirect {url {permanent 0}} {
> no_body ; ## don’t output anything on a redirect
> headers set Location $url
> headers numeric [expr {$permanent ? "301" : "302"}]
> abort_page ; ## stop any further processing
> }
>
> Damon
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Ronnie Brunner <ro...@netcetera.com>.
Hi folks
> >
> > Glad to hear it! I'm sure Massimo would love some company.
> >
+1 :-)
> Which actually brings up something I've been thinking about for a while.
>
> Do we want to keep Rivet under the Apache umbrella? Do we gain
> anything from being an Apache project, really? Or is it just a lot
> of bureaucracy we have to suffer through?
It seems it got much worse lately, but it could also be that it was
just updating some stuff that wasn't done for a while... I don't
generally think that it's really hindering anybody from contributing
or going somewhere.
Knowing that this is a pretty bland statement, I guess the point I
try to make is: shouldn't the effort go into actually working on Rivet
rather that wondering if not working on it would be much is easier
somewhere else? ;-) (Obviously I'm speaking for myself and a few
others, but definitly not for Massimo: I always appreciate his
work.)
Gruess us Züri
Ronnie
--
Ronnie Brunner | ronnie.brunner@netcetera.com | T +41 44 297 59 79 |
Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com |
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Massimo Manghi <mx...@apache.org>.
On 17-12-2014 17:08, Massimo Manghi wrote:
[...]
> What the behavior we expect in this case (it would imply we should
> call?
sorry, this line should read simply
What the behavior we expect in this case?
-- M
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Massimo Manghi <mx...@apache.org>.
On 12/17/2014 05:34 PM, Damon Courtney wrote:
> I’m guessing the reason we don’t get an error is because of the
> [no_body] command in there, so the error isn’t getting output. I
yes
TCL_CMD_HEADER( Rivet_NoBody )
{
rivet_interp_globals *globals =
Tcl_GetAssocData(interp, "rivet", NULL);
CHECK_REQUEST_REC(globals->r,"::rivet::no_body");
if (globals->req->content_sent == 1) {
Tcl_AddErrorInfo(interp, "Content already sent");
return TCL_ERROR;
}
globals->req->content_sent = 1;
return TCL_OK;
}
if globals->req->content_sent == 1 then outputproc won't send any data
down the connection through ap_write
TclWeb_PrintHeaders(private->req);
if (private->req->content_sent == 0)
{
ap_rwrite(buf, toWrite, private->r);
ap_rflush(private->r);
}
I was wrong about the flush method of Rivet channel: flush methods are
declared but...for future use, there is no support
> would suggest adding a [headers sent] command that simply returns
> whether the headers have gone out already, and then we use that in
> ::rivet::redirect to return an error.
>
> The [headers] command has the correct behavior that errors out when
> the headers have already been sent, but we’ve now prevented the error
> from displaying to the user.
>
OK
> Also, looking at the code, I think we have a discrepancy in the
> [headers] command. The docs imply that most of the arguments to the
> command are optional, but the code says otherwise. For example, the
> docs say:
>
> headers set ?headername? ?value?
>
> The ?’s imply that both headername and value are optional arguments.
> I read that to mean that [headers set] by itself will probably return
> a dict of headers (it doesn’t), and [headers set Some-Header] will
> return the current value of the Some-Header header (it doesn’t).
>
> Changing the docs is the quickest course of action. HOWEVER, it is a
> very Tcl’ish thing to do to have the kind of introspection that would
> be provided by making the headers command arguments actually be
> optional with the behavior I’ve described above.
I will put it in the TODO list
>
> Anyone know what stupid-ass process I have to go through to get
> committer access with Apache? I haven’t been a committer in a long,
> long time, but I’ve been working pretty steadily in Rivet for a few
> years now, and there are nits I would love to fix. I hate that
> Massimo is the only guy who’s ever in the code. I should get my hands
> dirty. :)
>
you're very welcome! In case my intervention is requested let me know of
anything I have to do as project chair in order to restore your account
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Massimo Manghi <mx...@apache.org>.
On 12/17/2014 06:05 PM, David Welton wrote:
> Glad to hear it! I'm sure Massimo would love some company.
Yes, after I read this line I felt I was like Charlton Heston in "The
Omega Man" (http://en.wikipedia.org/wiki/The_Omega_Man) :)
>
> http://people.apache.org/committer-index.html#damonc shows you as
> still being an ASF member, committter, etc....
>
> Hopefully it's just a matter of restoring your login credentials.
>
I must be possible, had Damon been expunged from the ASF database the
email address based at apache.org wouldn't work anymore.
http://www.apache.org/dev/committers.html#help-i-forgot-my-password
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Massimo Manghi <ma...@unipr.it>.
Hello Rani
This message looks directed to Damon, but I presume I'm supposed to answer.
No, I won't make a video on Rivet's internals, it would take too long to
me and honestly I can't see the benefits. Something for self-instruction
about Apache and module development would make more sense when it comes
to the web server architecture, but in this case too I don't see how it
could make C language understanding any easier than reading Nick Kew's
book (for Apache module) and browsing a good C language resource for the
programming, either on a book or the Internet.
cheers
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Rani Ahmed <ra...@gmail.com>.
I will get my hands dirty in the code too, if you provide me videos that
explains to me the codes of the Rivet project. It's also worth it and it's
also a good revision of the code. Also this way it will ease
understanding the way you think in the project. I know C programming, but I
am weak in it because I had no practical serious projects to with it.
On Wednesday, December 17, 2014, Damon Courtney <da...@tclhome.com> wrote:
> Which actually brings up something I’ve been thinking about for a while.
>
> Do we want to keep Rivet under the Apache umbrella? Do we gain anything
> from being an Apache project, really? Or is it just a lot of bureaucracy we
> have to suffer through?
>
> My feeling is the latter. :(
>
> D
>
>
> > On Dec 17, 2014, at 11:05 AM, David Welton <davidw@dedasys.com
> <javascript:;>> wrote:
> >
> >> Anyone know what stupid-ass process I have to go through to get
> committer access with Apache? I haven’t been a committer in a long, long
> time, but I’ve been working pretty steadily in Rivet for a few years now,
> and there are nits I would love to fix. I hate that Massimo is the only guy
> who’s ever in the code. I should get my hands dirty. :)
> >
> > Glad to hear it! I'm sure Massimo would love some company.
> >
> > http://people.apache.org/committer-index.html#damonc shows you as
> > still being an ASF member, committter, etc....
> >
> > Hopefully it's just a matter of restoring your login credentials.
> >
> > --
> > David N. Welton
> >
> > http://www.dedasys.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> <javascript:;>
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
> <javascript:;>
>
>
Re: To stay or not to stay [was: Hi. A suggestion.]
Posted by Massimo Manghi <mx...@apache.org>.
On 12/18/2014 09:50 PM, Damon Courtney wrote:
> So, the message I’m getting is that I’m the only one here. :) That’s
> cool. Just throwing it out there as a suggestion.
I appreciated the intention, it was quite stale here, inevitably. I
don't think your suggestion should be thrown away: quite timely Jeff
pointed out that many ASF projects are actually mirrored on github and
there is a lot of exchange with that part of the world. I thought for a
minute to move to git but I examined only the technical aspect (and I
didn't see a urge for that) and overlooked entirely the social implications
>
> Massimo is right that there should probably be a lot more sharing of
> what we’re working on. Honestly, though, I think one of the reasons
> we don’t hear much about Tcl (and, by extension, Rivet) is because
> all of the people using it are probably in the “I’m too old to brag
> about shit, I’m just here to get my work done” crowd. That’s my
> inclination anyway.
>
> I’ve done a lot of work in Rivet. I’ve been working with Tcl in one
> form or another for the last 20 years (thanks, Karl!). I just don’t
> have much time for showing everyone, explaining it, and then
> supporting it for others who want to use it. That’s probably a
> selfish attitude, but I’ve been screwed by the open source crowd
> before. The whole “stone soup” idea is great, and I still believe in
> it, but more often than not, I see one or two people doing the work
> and everyone else complaining.
>
> Sorry, that’s a bit of rant I didn’t mean to get off on. Yes, we
> should show off some of the stuff we’ve been working on. I know
> Flightaware has a repo on GitHub where the post some of their cool
> stuff. I’ve got a whole MVC framework I built in Rivet that I’m not
> ready to show wide, and it probably sucks, but I really like it. :)
I feel the same about my creature, completely, but I think I would like
to be part of a creative moment, where people throw their experience and
talent to do something. I will "grab the bull by both the horns" (like
we Italians say when you have to undertake something with decision) and
trim a bit my stuff. I will let it go into the world otherwise, like our
children, it will never grow up. But I need a few weeks, Christmas is
coming, family claims more time and I'm writing a paper
>
> Maybe we need a place on the website that points to projects
> connected to Rivet. Just a title and a link (probably to a GitHub
> repo) is good, but maybe a short description of the project as well.
>
>
> Or, maybe we’re all gettin’ too old for this shit.
>
oh please, don't say so. Let's try to get the best from this situation
> D
>
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: To stay or not to stay [was: Hi. A suggestion.]
Posted by Massimo Manghi <mx...@apache.org>.
Brice, thank you for sharing your experience, I think your case should
be taken as guidance for us in order to understand to which direction
the project should be shepherded
+1, +10 , +100 for improving the docs. I think DocBook is really
unattractive. It's never an attractive duty for me to put my hands on
the XML of the manual, furthermore the markup it's not used coherently
throughout the manual and I confess I mostly copy sections as templates
for developing new parts, having failed to understand the power and the
magic of DocBook. I'd like to find a way out of it.
.. Massimo
On 12/18/2014 10:56 PM, Brice Hamon wrote:
> Hi guys,
>
> Been a newbie on Rivet does not give me inside on what was good before,
> what we have done etc.. But I wanted to share my Rivet story with you.
>
> Just a little background on me, I have 20+ years of C/C++ programming in
> distributed real time systems mostly on Unix. So web and scripting stuff is
> not my forte. Too slow in my world.
>
> But from my experience, when I looked for a web framework to develop a real
> time website, I chose Rivet because, FIRST it was under the Apache umbrella
> (granted it does not mean much but gives a certain degree of credibility).
> The second was because of the nature of my field, I needed a framework I
> could extend in C/C++ and TCL offers that very well. And fast.
>
> My outsider views made me realize that Rivet has a lot of features, works
> very well and is very fast. Perfect. On the other hand, the documentation
> is poor, does not promote the usage of this tool. Just building and running
> it correctly wasn't easy on OpenSuse and thanks to Harald and Massimo to
> get me going.
>
> So IMO breaking away from Apache will remove the Apache flag from the
> project and I fail to see the upside, outside the bureaucratic aspect of it.
>
> I agree with the idea of having Rivet's project samples gitted somewhere.
> First creating a simple website but showing all classic feature of Rivet
> would be nice to get a taste of this amazing product (as sometimes I hear
> you talking about undocumented command I never used but most likely I
> should). I had that topic on my TO DO list but unfortunately I have been
> very busy building my new-co. I am in better shape now and would start
> contributing to it.
>
> My 2 cents.
>
> Brice.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: To stay or not to stay [was: Hi. A suggestion.]
Posted by Brice Hamon <no...@gmail.com>.
Hi guys,
Been a newbie on Rivet does not give me inside on what was good before,
what we have done etc.. But I wanted to share my Rivet story with you.
Just a little background on me, I have 20+ years of C/C++ programming in
distributed real time systems mostly on Unix. So web and scripting stuff is
not my forte. Too slow in my world.
But from my experience, when I looked for a web framework to develop a real
time website, I chose Rivet because, FIRST it was under the Apache umbrella
(granted it does not mean much but gives a certain degree of credibility).
The second was because of the nature of my field, I needed a framework I
could extend in C/C++ and TCL offers that very well. And fast.
My outsider views made me realize that Rivet has a lot of features, works
very well and is very fast. Perfect. On the other hand, the documentation
is poor, does not promote the usage of this tool. Just building and running
it correctly wasn't easy on OpenSuse and thanks to Harald and Massimo to
get me going.
So IMO breaking away from Apache will remove the Apache flag from the
project and I fail to see the upside, outside the bureaucratic aspect of it.
I agree with the idea of having Rivet's project samples gitted somewhere.
First creating a simple website but showing all classic feature of Rivet
would be nice to get a taste of this amazing product (as sometimes I hear
you talking about undocumented command I never used but most likely I
should). I had that topic on my TO DO list but unfortunately I have been
very busy building my new-co. I am in better shape now and would start
contributing to it.
My 2 cents.
Brice.
On Thu, Dec 18, 2014 at 3:50 PM, Damon Courtney <da...@tclhome.com> wrote:
>
> So, the message I’m getting is that I’m the only one here. :) That’s cool.
> Just throwing it out there as a suggestion.
>
> Massimo is right that there should probably be a lot more sharing of what
> we’re working on. Honestly, though, I think one of the reasons we don’t
> hear much about Tcl (and, by extension, Rivet) is because all of the people
> using it are probably in the “I’m too old to brag about shit, I’m just here
> to get my work done” crowd. That’s my inclination anyway.
>
> I’ve done a lot of work in Rivet. I’ve been working with Tcl in one form
> or another for the last 20 years (thanks, Karl!). I just don’t have much
> time for showing everyone, explaining it, and then supporting it for others
> who want to use it. That’s probably a selfish attitude, but I’ve been
> screwed by the open source crowd before. The whole “stone soup” idea is
> great, and I still believe in it, but more often than not, I see one or two
> people doing the work and everyone else complaining.
>
> Sorry, that’s a bit of rant I didn’t mean to get off on. Yes, we should
> show off some of the stuff we’ve been working on. I know Flightaware has a
> repo on GitHub where the post some of their cool stuff. I’ve got a whole
> MVC framework I built in Rivet that I’m not ready to show wide, and it
> probably sucks, but I really like it. :)
>
> Maybe we need a place on the website that points to projects connected to
> Rivet. Just a title and a link (probably to a GitHub repo) is good, but
> maybe a short description of the project as well.
>
> Or, maybe we’re all gettin’ too old for this shit.
>
> D
>
>
> On Dec 18, 2014, at 1:38 PM, Jeff Lawson <je...@bovine.net> wrote:
>
> I do think that the Apache relationship improves the perception of the
> project to outsiders in a positive way, and separating would potentially
> cause new users to have greater skepticism about Rivet. Also, just having
> to explain the fact that it is no longer an Apache project could be
> perceived slightly negatively.
>
> Some Apache projects choose to use git instead of subversion, which might
> make it easier for other users to submit code changes via pull requests:
> https://git-wip-us.apache.org/
>
>
> On Thu, Dec 18, 2014 at 11:05 AM, Damon Courtney <da...@tclhome.com>
> wrote:
>>
>> Tcl is not a popular language. It’s not GOING to be a popular language.
>> Nothing we do in Rivet will change that. Although, Rails made Ruby popular,
>> so who knows. I don’t care. I use what I like and will continue to do so.
>>
>> The point was simply that the open source world is much more vibrant in
>> places NOT ruled by bureaucracy. No, we’re not going to get a herd of
>> programmers take a look at Rivet by going somewhere else, but having
>> everyone jump through stupid hoops to even try can’t help. I’ll admit that
>> this is purely self-serving on my part. I don’t want to have to jump
>> through the stupid hoops either. Not when I can just grab any project off
>> Github that I want and start working in minutes.
>>
>> I suppose the Apache project lends some credibility (for some), but I
>> don’t see it much these days. Any project that wants to attract attention
>> now lives on Github. Do we really want to keep voting and submitting
>> quarterly updates about how nothing is really happening? Or getting
>> chastised for not sending said reports?
>>
>> Also, holy shit, are we still f*cking using Subversion?! This makes the
>> whole Apache Project look like asshats. Ridiculous.
>>
>> D
>>
>>
>> > On Dec 18, 2014, at 3:40 AM, David Welton <da...@dedasys.com> wrote:
>> >
>> >> ASF is somewhat bureaucratic and rigid, no doubt. It's grown a lot and
>> >> became tailored to let many large projects coexist. I wasn't a
>> committer or
>> >> member in the early times, but I always thought ASF was a collection of
>> >> projects which had at the center the Apache HTTP Web Server. Apache
>> Tcl fits
>> >> exactly this model, and it would all the more so if we consider also
>> the
>> >> projects we dropped because unmaintained (mod_tcl, etc). But the web
>> server
>> >> (despite being still central for the Internet at large) is not the
>> core of
>> >> ASF anymore. There are ~150 projects in ASF, some of them really,
>> really big
>> >> and with large and thriving communities. I was impressed by the number
>> of
>> >> top level projects Apache Hadoop gave birth. We don't fit this picture
>> >> anymore, unquestionable. Recently on the board list someone pointed
>> out that
>> >> Apache never accepted umbrella projects in order to have a more timely
>> and
>> >> accountable management. Well...Apache Tcl is an umbrella project, we
>> >> declared it at the beginning of our home page, in very first statement.
>> >> Definitely we are misplaced if you see it this way.
>> >
>> > I think at one point, being associated with the Apache web server had
>> > some cachet. These days, most Apache projects are Java things that
>> > don't have any cross over with the web server, Tcl or Rivet.
>> >
>> > The rigidity and process and all that are a good thing for companies
>> > who want to interact with Apache, as there's a predictable, mostly
>> > friendly model for how things work, that produces code without legal
>> > issues. I don't think those are advantages for Rivet.
>> >
>> >> On the other hand we are tightly connected to the Apache web server
>> and I
>> >> see some danger ahead. It happened to me recently to show a young
>> engineer a
>> >> project I did using Rivet and Tcl. He didn't know of Tcl and became
>> >> suspicious of it. I could only mitigate his perplexity when I showed
>> Rivet
>> >> is developed under the hat of ASF. Branding is a key problem, also in
>> the
>> >> Open Source world.
>> >
>> > Interesting - what kind of background does he have in terms of
>> programming?
>> >
>> > OTOH, I'm not exactly sure there are vast herds of programmers just
>> > milling around waiting to start contributing to Rivet if only it
>> > weren't under the yoke of the ASF, either....
>> >
>> > --
>> > David N. Welton
>> >
>> > http://www.dedasys.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
>> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>>
>>
>
Re: To stay or not to stay [was: Hi. A suggestion.]
Posted by Damon Courtney <da...@tclhome.com>.
So, the message I’m getting is that I’m the only one here. :) That’s cool. Just throwing it out there as a suggestion.
Massimo is right that there should probably be a lot more sharing of what we’re working on. Honestly, though, I think one of the reasons we don’t hear much about Tcl (and, by extension, Rivet) is because all of the people using it are probably in the “I’m too old to brag about shit, I’m just here to get my work done” crowd. That’s my inclination anyway.
I’ve done a lot of work in Rivet. I’ve been working with Tcl in one form or another for the last 20 years (thanks, Karl!). I just don’t have much time for showing everyone, explaining it, and then supporting it for others who want to use it. That’s probably a selfish attitude, but I’ve been screwed by the open source crowd before. The whole “stone soup” idea is great, and I still believe in it, but more often than not, I see one or two people doing the work and everyone else complaining.
Sorry, that’s a bit of rant I didn’t mean to get off on. Yes, we should show off some of the stuff we’ve been working on. I know Flightaware has a repo on GitHub where the post some of their cool stuff. I’ve got a whole MVC framework I built in Rivet that I’m not ready to show wide, and it probably sucks, but I really like it. :)
Maybe we need a place on the website that points to projects connected to Rivet. Just a title and a link (probably to a GitHub repo) is good, but maybe a short description of the project as well.
Or, maybe we’re all gettin’ too old for this shit.
D
> On Dec 18, 2014, at 1:38 PM, Jeff Lawson <je...@bovine.net> wrote:
>
> I do think that the Apache relationship improves the perception of the project to outsiders in a positive way, and separating would potentially cause new users to have greater skepticism about Rivet. Also, just having to explain the fact that it is no longer an Apache project could be perceived slightly negatively.
>
> Some Apache projects choose to use git instead of subversion, which might make it easier for other users to submit code changes via pull requests:
> https://git-wip-us.apache.org/ <https://git-wip-us.apache.org/>
>
>
> On Thu, Dec 18, 2014 at 11:05 AM, Damon Courtney <damon@tclhome.com <ma...@tclhome.com>> wrote:
> Tcl is not a popular language. It’s not GOING to be a popular language. Nothing we do in Rivet will change that. Although, Rails made Ruby popular, so who knows. I don’t care. I use what I like and will continue to do so.
>
> The point was simply that the open source world is much more vibrant in places NOT ruled by bureaucracy. No, we’re not going to get a herd of programmers take a look at Rivet by going somewhere else, but having everyone jump through stupid hoops to even try can’t help. I’ll admit that this is purely self-serving on my part. I don’t want to have to jump through the stupid hoops either. Not when I can just grab any project off Github that I want and start working in minutes.
>
> I suppose the Apache project lends some credibility (for some), but I don’t see it much these days. Any project that wants to attract attention now lives on Github. Do we really want to keep voting and submitting quarterly updates about how nothing is really happening? Or getting chastised for not sending said reports?
>
> Also, holy shit, are we still f*cking using Subversion?! This makes the whole Apache Project look like asshats. Ridiculous.
>
> D
>
>
> > On Dec 18, 2014, at 3:40 AM, David Welton <davidw@dedasys.com <ma...@dedasys.com>> wrote:
> >
> >> ASF is somewhat bureaucratic and rigid, no doubt. It's grown a lot and
> >> became tailored to let many large projects coexist. I wasn't a committer or
> >> member in the early times, but I always thought ASF was a collection of
> >> projects which had at the center the Apache HTTP Web Server. Apache Tcl fits
> >> exactly this model, and it would all the more so if we consider also the
> >> projects we dropped because unmaintained (mod_tcl, etc). But the web server
> >> (despite being still central for the Internet at large) is not the core of
> >> ASF anymore. There are ~150 projects in ASF, some of them really, really big
> >> and with large and thriving communities. I was impressed by the number of
> >> top level projects Apache Hadoop gave birth. We don't fit this picture
> >> anymore, unquestionable. Recently on the board list someone pointed out that
> >> Apache never accepted umbrella projects in order to have a more timely and
> >> accountable management. Well...Apache Tcl is an umbrella project, we
> >> declared it at the beginning of our home page, in very first statement.
> >> Definitely we are misplaced if you see it this way.
> >
> > I think at one point, being associated with the Apache web server had
> > some cachet. These days, most Apache projects are Java things that
> > don't have any cross over with the web server, Tcl or Rivet.
> >
> > The rigidity and process and all that are a good thing for companies
> > who want to interact with Apache, as there's a predictable, mostly
> > friendly model for how things work, that produces code without legal
> > issues. I don't think those are advantages for Rivet.
> >
> >> On the other hand we are tightly connected to the Apache web server and I
> >> see some danger ahead. It happened to me recently to show a young engineer a
> >> project I did using Rivet and Tcl. He didn't know of Tcl and became
> >> suspicious of it. I could only mitigate his perplexity when I showed Rivet
> >> is developed under the hat of ASF. Branding is a key problem, also in the
> >> Open Source world.
> >
> > Interesting - what kind of background does he have in terms of programming?
> >
> > OTOH, I'm not exactly sure there are vast herds of programmers just
> > milling around waiting to start contributing to Rivet if only it
> > weren't under the yoke of the ASF, either....
> >
> > --
> > David N. Welton
> >
> > http://www.dedasys.com/ <http://www.dedasys.com/>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org <ma...@tcl.apache.org>
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org <ma...@tcl.apache.org>
>
Re: To stay or not to stay [was: Hi. A suggestion.]
Posted by Jeff Lawson <je...@bovine.net>.
I do think that the Apache relationship improves the perception of the
project to outsiders in a positive way, and separating would potentially
cause new users to have greater skepticism about Rivet. Also, just having
to explain the fact that it is no longer an Apache project could be
perceived slightly negatively.
Some Apache projects choose to use git instead of subversion, which might
make it easier for other users to submit code changes via pull requests:
https://git-wip-us.apache.org/
On Thu, Dec 18, 2014 at 11:05 AM, Damon Courtney <da...@tclhome.com> wrote:
>
> Tcl is not a popular language. It’s not GOING to be a popular language.
> Nothing we do in Rivet will change that. Although, Rails made Ruby popular,
> so who knows. I don’t care. I use what I like and will continue to do so.
>
> The point was simply that the open source world is much more vibrant in
> places NOT ruled by bureaucracy. No, we’re not going to get a herd of
> programmers take a look at Rivet by going somewhere else, but having
> everyone jump through stupid hoops to even try can’t help. I’ll admit that
> this is purely self-serving on my part. I don’t want to have to jump
> through the stupid hoops either. Not when I can just grab any project off
> Github that I want and start working in minutes.
>
> I suppose the Apache project lends some credibility (for some), but I
> don’t see it much these days. Any project that wants to attract attention
> now lives on Github. Do we really want to keep voting and submitting
> quarterly updates about how nothing is really happening? Or getting
> chastised for not sending said reports?
>
> Also, holy shit, are we still f*cking using Subversion?! This makes the
> whole Apache Project look like asshats. Ridiculous.
>
> D
>
>
> > On Dec 18, 2014, at 3:40 AM, David Welton <da...@dedasys.com> wrote:
> >
> >> ASF is somewhat bureaucratic and rigid, no doubt. It's grown a lot and
> >> became tailored to let many large projects coexist. I wasn't a
> committer or
> >> member in the early times, but I always thought ASF was a collection of
> >> projects which had at the center the Apache HTTP Web Server. Apache Tcl
> fits
> >> exactly this model, and it would all the more so if we consider also the
> >> projects we dropped because unmaintained (mod_tcl, etc). But the web
> server
> >> (despite being still central for the Internet at large) is not the core
> of
> >> ASF anymore. There are ~150 projects in ASF, some of them really,
> really big
> >> and with large and thriving communities. I was impressed by the number
> of
> >> top level projects Apache Hadoop gave birth. We don't fit this picture
> >> anymore, unquestionable. Recently on the board list someone pointed out
> that
> >> Apache never accepted umbrella projects in order to have a more timely
> and
> >> accountable management. Well...Apache Tcl is an umbrella project, we
> >> declared it at the beginning of our home page, in very first statement.
> >> Definitely we are misplaced if you see it this way.
> >
> > I think at one point, being associated with the Apache web server had
> > some cachet. These days, most Apache projects are Java things that
> > don't have any cross over with the web server, Tcl or Rivet.
> >
> > The rigidity and process and all that are a good thing for companies
> > who want to interact with Apache, as there's a predictable, mostly
> > friendly model for how things work, that produces code without legal
> > issues. I don't think those are advantages for Rivet.
> >
> >> On the other hand we are tightly connected to the Apache web server and
> I
> >> see some danger ahead. It happened to me recently to show a young
> engineer a
> >> project I did using Rivet and Tcl. He didn't know of Tcl and became
> >> suspicious of it. I could only mitigate his perplexity when I showed
> Rivet
> >> is developed under the hat of ASF. Branding is a key problem, also in
> the
> >> Open Source world.
> >
> > Interesting - what kind of background does he have in terms of
> programming?
> >
> > OTOH, I'm not exactly sure there are vast herds of programmers just
> > milling around waiting to start contributing to Rivet if only it
> > weren't under the yoke of the ASF, either....
> >
> > --
> > David N. Welton
> >
> > http://www.dedasys.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
>
Re: To stay or not to stay [was: Hi. A suggestion.]
Posted by Massimo Manghi <mx...@apache.org>.
I think your first paragraph shows the crux of the problem and hints a
direction to follow: there is no urgent need to move Rivet out of ASF
because Tcl is not a buzzword in the open source community and it's
unlikely to become so just because gets labeled with 'fork me on
github'. We could probably move out with Rivet (and your arguments are
quite strong for it) if we had something to lay on Rivet itself that
might attract Tcl'ers who are now drawing on more popular languages when
it comes to web programming. And web programming is ubiquitous because
web technology comes handy in many different scopes and I'm certain many
Tcl'ers go to PHP, Java or Rails for building websites even when they
don't need all the power of those long established tools and don't have
strong branding requirements (yes, people like to see those shiny words
on what they paid for)
Maybe it's time we throw into the arena what we have done in these
years, let it be torn into pieces, criticized and reassembled in
something that might look attractive at least for those who have already
a penchant for Tcl.
If you allow a few more weeks I will start myself presenting what I've
been doing in the last 2 years with Rivet and what I did with it. Don't
expect anything perfect, but I made with it quite a few websites for
various purposes
-- Massimo
On 12/18/2014 06:05 PM, Damon Courtney wrote:
> Tcl is not a popular language. It’s not GOING to be a popular
> language. Nothing we do in Rivet will change that. Although, Rails
> made Ruby popular, so who knows. I don’t care. I use what I like and
> will continue to do so.
>
> The point was simply that the open source world is much more vibrant
> in places NOT ruled by bureaucracy. No, we’re not going to get a herd
> of programmers take a look at Rivet by going somewhere else, but
> having everyone jump through stupid hoops to even try can’t help.
> I’ll admit that this is purely self-serving on my part. I don’t want
> to have to jump through the stupid hoops either. Not when I can just
> grab any project off Github that I want and start working in
> minutes.
>
> I suppose the Apache project lends some credibility (for some), but I
> don’t see it much these days. Any project that wants to attract
> attention now lives on Github. Do we really want to keep voting and
> submitting quarterly updates about how nothing is really happening?
> Or getting chastised for not sending said reports?
>
> Also, holy shit, are we still f*cking using Subversion?! This makes
> the whole Apache Project look like asshats. Ridiculous.
>
> D
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: To stay or not to stay [was: Hi. A suggestion.]
Posted by Damon Courtney <da...@tclhome.com>.
Tcl is not a popular language. It’s not GOING to be a popular language. Nothing we do in Rivet will change that. Although, Rails made Ruby popular, so who knows. I don’t care. I use what I like and will continue to do so.
The point was simply that the open source world is much more vibrant in places NOT ruled by bureaucracy. No, we’re not going to get a herd of programmers take a look at Rivet by going somewhere else, but having everyone jump through stupid hoops to even try can’t help. I’ll admit that this is purely self-serving on my part. I don’t want to have to jump through the stupid hoops either. Not when I can just grab any project off Github that I want and start working in minutes.
I suppose the Apache project lends some credibility (for some), but I don’t see it much these days. Any project that wants to attract attention now lives on Github. Do we really want to keep voting and submitting quarterly updates about how nothing is really happening? Or getting chastised for not sending said reports?
Also, holy shit, are we still f*cking using Subversion?! This makes the whole Apache Project look like asshats. Ridiculous.
D
> On Dec 18, 2014, at 3:40 AM, David Welton <da...@dedasys.com> wrote:
>
>> ASF is somewhat bureaucratic and rigid, no doubt. It's grown a lot and
>> became tailored to let many large projects coexist. I wasn't a committer or
>> member in the early times, but I always thought ASF was a collection of
>> projects which had at the center the Apache HTTP Web Server. Apache Tcl fits
>> exactly this model, and it would all the more so if we consider also the
>> projects we dropped because unmaintained (mod_tcl, etc). But the web server
>> (despite being still central for the Internet at large) is not the core of
>> ASF anymore. There are ~150 projects in ASF, some of them really, really big
>> and with large and thriving communities. I was impressed by the number of
>> top level projects Apache Hadoop gave birth. We don't fit this picture
>> anymore, unquestionable. Recently on the board list someone pointed out that
>> Apache never accepted umbrella projects in order to have a more timely and
>> accountable management. Well...Apache Tcl is an umbrella project, we
>> declared it at the beginning of our home page, in very first statement.
>> Definitely we are misplaced if you see it this way.
>
> I think at one point, being associated with the Apache web server had
> some cachet. These days, most Apache projects are Java things that
> don't have any cross over with the web server, Tcl or Rivet.
>
> The rigidity and process and all that are a good thing for companies
> who want to interact with Apache, as there's a predictable, mostly
> friendly model for how things work, that produces code without legal
> issues. I don't think those are advantages for Rivet.
>
>> On the other hand we are tightly connected to the Apache web server and I
>> see some danger ahead. It happened to me recently to show a young engineer a
>> project I did using Rivet and Tcl. He didn't know of Tcl and became
>> suspicious of it. I could only mitigate his perplexity when I showed Rivet
>> is developed under the hat of ASF. Branding is a key problem, also in the
>> Open Source world.
>
> Interesting - what kind of background does he have in terms of programming?
>
> OTOH, I'm not exactly sure there are vast herds of programmers just
> milling around waiting to start contributing to Rivet if only it
> weren't under the yoke of the ASF, either....
>
> --
> David N. Welton
>
> http://www.dedasys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: To stay or not to stay [was: Hi. A suggestion.]
Posted by David Welton <da...@dedasys.com>.
> ASF is somewhat bureaucratic and rigid, no doubt. It's grown a lot and
> became tailored to let many large projects coexist. I wasn't a committer or
> member in the early times, but I always thought ASF was a collection of
> projects which had at the center the Apache HTTP Web Server. Apache Tcl fits
> exactly this model, and it would all the more so if we consider also the
> projects we dropped because unmaintained (mod_tcl, etc). But the web server
> (despite being still central for the Internet at large) is not the core of
> ASF anymore. There are ~150 projects in ASF, some of them really, really big
> and with large and thriving communities. I was impressed by the number of
> top level projects Apache Hadoop gave birth. We don't fit this picture
> anymore, unquestionable. Recently on the board list someone pointed out that
> Apache never accepted umbrella projects in order to have a more timely and
> accountable management. Well...Apache Tcl is an umbrella project, we
> declared it at the beginning of our home page, in very first statement.
> Definitely we are misplaced if you see it this way.
I think at one point, being associated with the Apache web server had
some cachet. These days, most Apache projects are Java things that
don't have any cross over with the web server, Tcl or Rivet.
The rigidity and process and all that are a good thing for companies
who want to interact with Apache, as there's a predictable, mostly
friendly model for how things work, that produces code without legal
issues. I don't think those are advantages for Rivet.
> On the other hand we are tightly connected to the Apache web server and I
> see some danger ahead. It happened to me recently to show a young engineer a
> project I did using Rivet and Tcl. He didn't know of Tcl and became
> suspicious of it. I could only mitigate his perplexity when I showed Rivet
> is developed under the hat of ASF. Branding is a key problem, also in the
> Open Source world.
Interesting - what kind of background does he have in terms of programming?
OTOH, I'm not exactly sure there are vast herds of programmers just
milling around waiting to start contributing to Rivet if only it
weren't under the yoke of the ASF, either....
--
David N. Welton
http://www.dedasys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
To stay or not to stay [was: Hi. A suggestion.]
Posted by Massimo Manghi <ma...@unipr.it>.
I never thought of this possibility. I always felt Rivet wasn't mine
after all and probably unconsciously never granted myself the right of
thinking in these terms.
ASF is somewhat bureaucratic and rigid, no doubt. It's grown a lot and
became tailored to let many large projects coexist. I wasn't a committer
or member in the early times, but I always thought ASF was a collection
of projects which had at the center the Apache HTTP Web Server. Apache
Tcl fits exactly this model, and it would all the more so if we consider
also the projects we dropped because unmaintained (mod_tcl, etc). But
the web server (despite being still central for the Internet at large)
is not the core of ASF anymore. There are ~150 projects in ASF, some of
them really, really big and with large and thriving communities. I was
impressed by the number of top level projects Apache Hadoop gave birth.
We don't fit this picture anymore, unquestionable. Recently on the board
list someone pointed out that Apache never accepted umbrella projects in
order to have a more timely and accountable management. Well...Apache
Tcl is an umbrella project, we declared it at the beginning of our home
page, in very first statement. Definitely we are misplaced if you see it
this way.
On the other hand we are tightly connected to the Apache web server and
I see some danger ahead. It happened to me recently to show a young
engineer a project I did using Rivet and Tcl. He didn't know of Tcl and
became suspicious of it. I could only mitigate his perplexity when I
showed Rivet is developed under the hat of ASF. Branding is a key
problem, also in the Open Source world.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Damon Courtney <da...@tclhome.com>.
Which actually brings up something I’ve been thinking about for a while.
Do we want to keep Rivet under the Apache umbrella? Do we gain anything from being an Apache project, really? Or is it just a lot of bureaucracy we have to suffer through?
My feeling is the latter. :(
D
> On Dec 17, 2014, at 11:05 AM, David Welton <da...@dedasys.com> wrote:
>
>> Anyone know what stupid-ass process I have to go through to get committer access with Apache? I haven’t been a committer in a long, long time, but I’ve been working pretty steadily in Rivet for a few years now, and there are nits I would love to fix. I hate that Massimo is the only guy who’s ever in the code. I should get my hands dirty. :)
>
> Glad to hear it! I'm sure Massimo would love some company.
>
> http://people.apache.org/committer-index.html#damonc shows you as
> still being an ASF member, committter, etc....
>
> Hopefully it's just a matter of restoring your login credentials.
>
> --
> David N. Welton
>
> http://www.dedasys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by David Welton <da...@dedasys.com>.
> Anyone know what stupid-ass process I have to go through to get committer access with Apache? I haven’t been a committer in a long, long time, but I’ve been working pretty steadily in Rivet for a few years now, and there are nits I would love to fix. I hate that Massimo is the only guy who’s ever in the code. I should get my hands dirty. :)
Glad to hear it! I'm sure Massimo would love some company.
http://people.apache.org/committer-index.html#damonc shows you as
still being an ASF member, committter, etc....
Hopefully it's just a matter of restoring your login credentials.
--
David N. Welton
http://www.dedasys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Massimo Manghi <ma...@unipr.it>.
On 12/17/2014 05:34 PM, Damon Courtney wrote:
> I’m guessing the reason we don’t get an error is because of the
> [no_body] command in there, so the error isn’t getting output. I
> would suggest adding a [headers sent] command that simply returns
> whether the headers have gone out already, and then we use that in
> ::rivet::redirect to return an error.
done and committed yesterday. Documentation still to be written
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Damon Courtney <da...@tclhome.com>.
I’m guessing the reason we don’t get an error is because of the [no_body] command in there, so the error isn’t getting output. I would suggest adding a [headers sent] command that simply returns whether the headers have gone out already, and then we use that in ::rivet::redirect to return an error.
The [headers] command has the correct behavior that errors out when the headers have already been sent, but we’ve now prevented the error from displaying to the user.
Also, looking at the code, I think we have a discrepancy in the [headers] command. The docs imply that most of the arguments to the command are optional, but the code says otherwise. For example, the docs say:
headers set ?headername? ?value?
The ?’s imply that both headername and value are optional arguments. I read that to mean that [headers set] by itself will probably return a dict of headers (it doesn’t), and [headers set Some-Header] will return the current value of the Some-Header header (it doesn’t).
Changing the docs is the quickest course of action. HOWEVER, it is a very Tcl’ish thing to do to have the kind of introspection that would be provided by making the headers command arguments actually be optional with the behavior I’ve described above.
Anyone know what stupid-ass process I have to go through to get committer access with Apache? I haven’t been a committer in a long, long time, but I’ve been working pretty steadily in Rivet for a few years now, and there are nits I would love to fix. I hate that Massimo is the only guy who’s ever in the code. I should get my hands dirty. :)
D
> On Dec 17, 2014, at 10:08 AM, Massimo Manghi <mx...@apache.org> wrote:
>
> There is an implication in using 'headers numeric 302' with the buffer
> control handling.
>
> I don't see any need for reducing the channel buffer size (especially
> since the rivet channel handling was modified in order to have a single
> channel per thread) but I tested the case where the buffer size was
> shrunk to a length short enough to cause several buffer outputs on a
> single page. I put a conditional redirect near the end of the page and
> triggered the redirection. The page don't divert (because headers had
> been flushed already), it stops outputting data, but it doesn't fail either.
>
> What the behavior we expect in this case (it would imply we should call?
> I would expect the page to fail or return a some special code in order
> to give us a chance to abort redirection and maybe take some action.
>
> What do you think?
>
> -- Massimo
>
>
> On 12/15/2014 11:00 PM, Damon Courtney wrote:
>> I had thought about that. I would vote for something extensible like a dict with a required field.
>>
>> ## For a straight abort_page
>> set d [dict create]
>> dict set d error_code “abort”
>>
>> ## For a redirect
>> set d [dict create]
>> dict set d error_code “redirect”
>> dict set d location [headers set Location]
>>
>> Or whatever. error_code being very Tcl’ish and the only required value. The others are dependent on the error_code value. It’s simple, and we can add other codes with other information later.
>>
>> D
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Massimo Manghi <mx...@apache.org>.
There is an implication in using 'headers numeric 302' with the buffer
control handling.
I don't see any need for reducing the channel buffer size (especially
since the rivet channel handling was modified in order to have a single
channel per thread) but I tested the case where the buffer size was
shrunk to a length short enough to cause several buffer outputs on a
single page. I put a conditional redirect near the end of the page and
triggered the redirection. The page don't divert (because headers had
been flushed already), it stops outputting data, but it doesn't fail either.
What the behavior we expect in this case (it would imply we should call?
I would expect the page to fail or return a some special code in order
to give us a chance to abort redirection and maybe take some action.
What do you think?
-- Massimo
On 12/15/2014 11:00 PM, Damon Courtney wrote:
> I had thought about that. I would vote for something extensible like a dict with a required field.
>
> ## For a straight abort_page
> set d [dict create]
> dict set d error_code “abort”
>
> ## For a redirect
> set d [dict create]
> dict set d error_code “redirect”
> dict set d location [headers set Location]
>
> Or whatever. error_code being very Tcl’ish and the only required value. The others are dependent on the error_code value. It’s simple, and we can add other codes with other information later.
>
> D
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Damon Courtney <da...@tclhome.com>.
I had thought about that. I would vote for something extensible like a dict with a required field.
## For a straight abort_page
set d [dict create]
dict set d error_code “abort”
## For a redirect
set d [dict create]
dict set d error_code “redirect”
dict set d location [headers set Location]
Or whatever. error_code being very Tcl’ish and the only required value. The others are dependent on the error_code value. It’s simple, and we can add other codes with other information later.
D
> On Dec 15, 2014, at 3:54 PM, Massimo Manghi <mx...@apache.org> wrote:
>
> In fact, I was just afraid that rushing a decision would spoil a more
> elegant way of encoding this (and other) conditions
>
> -- Massimo
>
> On 12/15/2014 10:51 PM, Damon Courtney wrote:
>> Can’t we just call [abort_page “redirect”] from the proc instead of
>> without an argument? Then at least someone can check the abort code
>> in their script to see that it’s a redirect and ignore it. Seems like
>> a pretty reasonable idea. :)
>>
>> D
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Massimo Manghi <mx...@apache.org>.
In fact, I was just afraid that rushing a decision would spoil a more
elegant way of encoding this (and other) conditions
-- Massimo
On 12/15/2014 10:51 PM, Damon Courtney wrote:
> Can’t we just call [abort_page “redirect”] from the proc instead of
> without an argument? Then at least someone can check the abort code
> in their script to see that it’s a redirect and ignore it. Seems like
> a pretty reasonable idea. :)
>
> D
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Damon Courtney <da...@tclhome.com>.
Can’t we just call [abort_page “redirect”] from the proc instead of without an argument? Then at least someone can check the abort code in their script to see that it’s a redirect and ignore it. Seems like a pretty reasonable idea. :)
D
> On Dec 15, 2014, at 3:43 PM, Massimo Manghi <mx...@apache.org> wrote:
>
> AbortScript could serve several different reasons for interrupting
> processing depending on the result returned by [::rivet::abort_code]. I
> will leave it without argument because it's harmless, but it could be a
> good reason for thinking of a 'rivet scheme' for encoding these
> exceptions in the abort_page argument. They can get the URL from
> Location but they need to know why execution got there in the first place
>
> -- M
>
> On 12/15/2014 10:20 PM, Damon Courtney wrote:
>> I would just abort with “redirect”. If they want the location, they can call [headers set Location] to get it.
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Massimo Manghi <mx...@apache.org>.
AbortScript could serve several different reasons for interrupting
processing depending on the result returned by [::rivet::abort_code]. I
will leave it without argument because it's harmless, but it could be a
good reason for thinking of a 'rivet scheme' for encoding these
exceptions in the abort_page argument. They can get the URL from
Location but they need to know why execution got there in the first place
-- M
On 12/15/2014 10:20 PM, Damon Courtney wrote:
> I would just abort with “redirect”. If they want the location, they can call [headers set Location] to get it.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Damon Courtney <da...@tclhome.com>.
I would just abort with “redirect”. If they want the location, they can call [headers set Location] to get it.
> On Dec 15, 2014, at 3:09 PM, Massimo Manghi <mx...@apache.org> wrote:
>
> Oh great thanks, I'm going to put in trunk and branches/2.2 right away.
>
> starting with 2.1 IIRC ::rivet::abort_page supports an optional code as
> argument, so that any AbortScript can figure out what caused the page to
> abort. Any Tcl object could work as argument (even a dictionary). Do you
> have suggestion?
>
> -- Massimo
>
> On 12/15/2014 06:51 PM, Damon Courtney wrote:
>> Don’t worry, I got it. :) And, I agree. I didn’t realize parse was doing a flush of the output. We should fix that.
>>
>> I also agree that redirect should cause an abort (or something like
>> it). I already do that in my own code, as it makes no sense to
>> redirect and then keep processing. It could potentially cause some
>> seriously confusing bugs. We could be more elegant about it in the C
>> code, but here’s a version of the proc I use we could include:
>>
>> proc ::rivet::redirect {url {permanent 0}} {
>> no_body ; ## don’t output anything on a redirect
>> headers set Location $url
>> headers numeric [expr {$permanent ? "301" : "302"}]
>> abort_page ; ## stop any further processing
>> }
>>
>> Damon
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Massimo Manghi <mx...@apache.org>.
Oh great thanks, I'm going to put in trunk and branches/2.2 right away.
starting with 2.1 IIRC ::rivet::abort_page supports an optional code as
argument, so that any AbortScript can figure out what caused the page to
abort. Any Tcl object could work as argument (even a dictionary). Do you
have suggestion?
-- Massimo
On 12/15/2014 06:51 PM, Damon Courtney wrote:
> Don’t worry, I got it. :) And, I agree. I didn’t realize parse was doing a flush of the output. We should fix that.
>
> I also agree that redirect should cause an abort (or something like
> it). I already do that in my own code, as it makes no sense to
> redirect and then keep processing. It could potentially cause some
> seriously confusing bugs. We could be more elegant about it in the C
> code, but here’s a version of the proc I use we could include:
>
> proc ::rivet::redirect {url {permanent 0}} {
> no_body ; ## don’t output anything on a redirect
> headers set Location $url
> headers numeric [expr {$permanent ? "301" : "302"}]
> abort_page ; ## stop any further processing
> }
>
> Damon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Damon Courtney <da...@tclhome.com>.
Don’t worry, I got it. :) And, I agree. I didn’t realize parse was doing a flush of the output. We should fix that.
I also agree that redirect should cause an abort (or something like it). I already do that in my own code, as it makes no sense to redirect and then keep processing. It could potentially cause some seriously confusing bugs. We could be more elegant about it in the C code, but here’s a version of the proc I use we could include:
proc ::rivet::redirect {url {permanent 0}} {
no_body ; ## don’t output anything on a redirect
headers set Location $url
headers numeric [expr {$permanent ? "301" : "302"}]
abort_page ; ## stop any further processing
}
Damon
> On Dec 15, 2014, at 11:43 AM, Massimo Manghi <ma...@unipr.it> wrote:
>
> I probably didn't express this point in an impeccable way. Let me rephrase it
>
> Even though Tcl_Flush (and implicitly the output method of Rivet channel) could be called when everything is done just before returning to Apache (true for most web pages), as a matter of fact parsing a subtemplate causes the same call to Tcl to occur and therefore becomes impossible in this case to change the headers. This is incoherent and fuzzy and should be fixed
>
> I hope the rest of my message is understandable.
>
> -- Massimo
>
>
> On 12/15/2014 04:13 PM, Massimo Manghi wrote:
>> I take it and I don't want you to leave the discussion ;)
>>
>> I've been repeating with Rani the same point every time he brought it
>> up: redirection should be done ASAP and before sending any data to the
>> stdout. I maintain that for any "sensible" page (most web pages size is
>> well < 1000000) data are sent when mod_rivet calls Tcl_Flush, therefore
>> redirection can occur before that point, but it's not true every case.
>> Rivet_ExecuteAndCheck calls Tcl_Flush which in turn causes Rivet
>> channel's output procedure to be called by Tcl. And this happens also
>> when the ::rivet::parse command is called (which calls
>> Rivet_ParseExecFile and then Rivet_ExecuteAndCheck)
>>
Re: Hi. A suggestion.
Posted by Massimo Manghi <ma...@unipr.it>.
I probably didn't express this point in an impeccable way. Let me
rephrase it
Even though Tcl_Flush (and implicitly the output method of Rivet
channel) could be called when everything is done just before returning
to Apache (true for most web pages), as a matter of fact parsing a
subtemplate causes the same call to Tcl to occur and therefore becomes
impossible in this case to change the headers. This is incoherent and
fuzzy and should be fixed
I hope the rest of my message is understandable.
-- Massimo
On 12/15/2014 04:13 PM, Massimo Manghi wrote:
> I take it and I don't want you to leave the discussion ;)
>
> I've been repeating with Rani the same point every time he brought it
> up: redirection should be done ASAP and before sending any data to the
> stdout. I maintain that for any "sensible" page (most web pages size is
> well < 1000000) data are sent when mod_rivet calls Tcl_Flush, therefore
> redirection can occur before that point, but it's not true every case.
> Rivet_ExecuteAndCheck calls Tcl_Flush which in turn causes Rivet
> channel's output procedure to be called by Tcl. And this happens also
> when the ::rivet::parse command is called (which calls
> Rivet_ParseExecFile and then Rivet_ExecuteAndCheck)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Hi. A suggestion.
Posted by Massimo Manghi <mx...@apache.org>.
I take it and I don't want you to leave the discussion ;)
I've been repeating with Rani the same point every time he brought it up:
redirection should be done ASAP and before sending any data to the stdout.
I maintain that for any "sensible" page (most web pages size is well <
1000000) data are sent when mod_rivet calls Tcl_Flush, therefore
redirection can occur before that point, but it's not true every case.
Rivet_ExecuteAndCheck calls Tcl_Flush which in turn causes Rivet channel's
output procedure to be called by Tcl. And this happens also when the
::rivet::parse command is called (which calls Rivet_ParseExecFile and then
Rivet_ExecuteAndCheck)
That's why redirection in most cases (my websites are always running nested
parsing) doesn't work if called during page generation and that's why I
perform most data generation within the BeforeScript, well before the top
level template is parsed. I think we could easily fix this collapsing every
Tcl_Flush call into a single call just before Rivet_SendContent exits.
Can we do any better? For example treating a 'headers redirect' call
likewise a ::rivet::abort_page call, maybe with it's specific code? After
all if you're redirecting what's the point of keep going with the page
generation? (As a matter of fact we could also empty the buffer and
invalidate any data produced)
I'm very conscious the channel is an ordinary Tcl channel and as such it
can be manipulated, but it doesn't exploit all the flexibility the Tcl
channel model offers. More specifically: only the output method is
implemented, but also the flush method could turn out useful in this case.
On Sat, Dec 13, 2014 at 7:50 PM, Damon Courtney <da...@tclhome.com> wrote:
>
> The channel mechanism is actually quite flexible out of the box. Anything
> Tcl lets you do, you can do with the stdout channel in Rivet. For example:
>
> fconfigure stdout -buffersize 1000000 -buffering full
>
> And you have almost a megabyte of output before the channel will flush
> (unless you [flush stdout] yourself).
>
> I know that having to output the headers before any data can be annoying
> sometimes, but it’s really the proper way to do it. If you’re going to
> redirect to another page, you should have done so LONG before you output
> any data. In my case, I’m using a pretty standard MVC model where the
> controller determines that a redirect is required before the view is ever
> rendered.
>
> If we wanted to try and support his proposal, we could alter the [headers
> redirect] command, and if headers have already been sent, then we output
> the <meta> tag, but this has its problems as well. Though most browsers
> would probably let it slide, the meta tag should really be inside the
> <head> of the page. So, once again, you have a limitation.
>
> Just my thoughts, take ‘em or leave ‘em. :)
>
> D
>
>
> On Dec 13, 2014, at 4:50 AM, Massimo Manghi <mx...@apache.org> wrote:
>
> Rani Ahmad gave me permission to forward to rivet-dev his proposal for an
> alternate way to force redirection to a different URL using the <meta ....>
> tag. Rani claims this approach could attain the same effect while
> preventing the scripts from failing with the "headers already sent" error.
> It still makes sense that a script which could issue a redirect has in
> principle to determine whether to divert to a different URL *before* any
> output is sent to the channel. admittedly this is rigid because forces a
> certain design (though a sane one), it's largely undocumented and in the
> end there should be a better more flexible way to do this
>
> We obtain redirection with the 301 HTTP code and when the headers command
> is called the code checks for the headers_sent flag
>
> TCL_CMD_HEADER( Rivet_Headers )
> {
> ...
> if (globals->req->headers_printed != 0)
> {
> Tcl_AddObjErrorInfo(interp ,"Cannot manipulate headers - already
> sent", -1);
> return TCL_ERROR;
> }
>
> globals->req->headers_printed is set when the Rivet channel output
> procedure is called by Tcl I/O subsystem and I wonder if there are
> different ways to do it, for example making the channel implementation more
> flexible about buffering. Of course this doesn't rule out the possibility
> of exploiting other ways (like in Rani's proposal), but it seems to me the
> HTTP protocol has to be supported in the best possible way
>
> -- Massimo
>
> ---------- Forwarded message ----------
> From: Rani Ahmed <ra...@gmail.com>
> Date: Thu, Dec 11, 2014 at 8:37 PM
> Subject: Hi. A suggestion.
> To: Massimo Manghi <mx...@apache.org>
>
> Hi Massimo.
>
> Well I suggest that you add a better redirect function/procedure other
> than the *[headers* redirect $url *]* . This one always makes many people
> go into the annoying error message of
>
> *headers already sent .*
> The procedur*e* will be the following, I found it on Stackoverflow. I
> understand that I can put it for my own, but this little thing - I think -
> can be the key that makes Rivet attractive.
>
> *proc* http_redirect *{* url *} {*
>
>
> *?>* <meta http-equiv="refresh" content="0;url='*<?=*$url;*?>*'">
> *<?*
>
> *}*
>
>
>
Re: Hi. A suggestion.
Posted by Damon Courtney <da...@tclhome.com>.
The channel mechanism is actually quite flexible out of the box. Anything Tcl lets you do, you can do with the stdout channel in Rivet. For example:
fconfigure stdout -buffersize 1000000 -buffering full
And you have almost a megabyte of output before the channel will flush (unless you [flush stdout] yourself).
I know that having to output the headers before any data can be annoying sometimes, but it’s really the proper way to do it. If you’re going to redirect to another page, you should have done so LONG before you output any data. In my case, I’m using a pretty standard MVC model where the controller determines that a redirect is required before the view is ever rendered.
If we wanted to try and support his proposal, we could alter the [headers redirect] command, and if headers have already been sent, then we output the <meta> tag, but this has its problems as well. Though most browsers would probably let it slide, the meta tag should really be inside the <head> of the page. So, once again, you have a limitation.
Just my thoughts, take ‘em or leave ‘em. :)
D
> On Dec 13, 2014, at 4:50 AM, Massimo Manghi <mx...@apache.org> wrote:
>
> Rani Ahmad gave me permission to forward to rivet-dev his proposal for an alternate way to force redirection to a different URL using the <meta ....> tag. Rani claims this approach could attain the same effect while preventing the scripts from failing with the "headers already sent" error. It still makes sense that a script which could issue a redirect has in principle to determine whether to divert to a different URL *before* any output is sent to the channel. admittedly this is rigid because forces a certain design (though a sane one), it's largely undocumented and in the end there should be a better more flexible way to do this
>
> We obtain redirection with the 301 HTTP code and when the headers command is called the code checks for the headers_sent flag
>
> TCL_CMD_HEADER( Rivet_Headers )
> {
> ...
> if (globals->req->headers_printed != 0)
> {
> Tcl_AddObjErrorInfo(interp ,"Cannot manipulate headers - already sent", -1);
> return TCL_ERROR;
> }
>
> globals->req->headers_printed is set when the Rivet channel output procedure is called by Tcl I/O subsystem and I wonder if there are different ways to do it, for example making the channel implementation more flexible about buffering. Of course this doesn't rule out the possibility of exploiting other ways (like in Rani's proposal), but it seems to me the HTTP protocol has to be supported in the best possible way
>
> -- Massimo
>
> ---------- Forwarded message ----------
> From: Rani Ahmed <ranixlb@gmail.com <ma...@gmail.com>>
> Date: Thu, Dec 11, 2014 at 8:37 PM
> Subject: Hi. A suggestion.
> To: Massimo Manghi <mxmanghi@apache.org <ma...@apache.org>>
>
> Hi Massimo.
>
> Well I suggest that you add a better redirect function/procedure other than the [headers redirect $url ] . This one always makes many people go into the annoying error message of headers already sent .
>
> The procedure will be the following, I found it on Stackoverflow. I understand that I can put it for my own, but this little thing - I think - can be the key that makes Rivet attractive.
>
> proc http_redirect { url } {
>
> ?>
> <meta http-equiv="refresh" content="0;url='<?=$url;?>'">
> <?
>
> }