Bruno Dumon wrote:
On Sat, 2003-11-01 at 16:20, Marc van Kempen wrote:
Bruno Dumon wrote:
On Fri, 2003-10-31 at 22:54, Marc van Kempen wrote:
Bruno Dumon wrote:
snip/
My first thought was to do this cleanup stuff serverside (could be as
simple as an XSL, which would make it easily
On Mon, 2003-11-03 at 14:59, Marc van Kempen wrote:
Bruno Dumon wrote:
On Sat, 2003-11-01 at 16:20, Marc van Kempen wrote:
Bruno Dumon wrote:
On Fri, 2003-10-31 at 22:54, Marc van Kempen wrote:
Bruno Dumon wrote:
snip/
My first thought was to do this cleanup stuff serverside
On Sat, 2003-11-01 at 16:20, Marc van Kempen wrote:
Bruno Dumon wrote:
On Fri, 2003-10-31 at 22:54, Marc van Kempen wrote:
Bruno Dumon wrote:
snip/
My first thought was to do this cleanup stuff serverside (could be as
simple as an XSL, which would make it easily customisable too).
On Fri, 2003-10-31 at 22:54, Marc van Kempen wrote:
Bruno Dumon wrote:
snip/
My first thought was to do this cleanup stuff serverside (could be as
simple as an XSL, which would make it easily customisable too). However
it seems like you want to do all that on the client side?
This
Bruno Dumon wrote:
...
* different users of the widget (like the doco project vs the project
where we need it) will likely require different subsets of HTML to be
used.
* support for both Mozilla and IE is important. Other browsers should
fall back to a textarea with raw HTML in it.
* the HTML
On Wednesday, Oct 29, 2003, at 11:40 Europe/Rome, Bruno Dumon wrote:
I've only just started with some little javascript experiments, so it's
not like any code has been written yet.
ok, but it's great to see you doing this
Here are some first random thoughts:
* different users of the widget
Bruno Dumon wrote:
I've only just started with some little javascript experiments, so it's
not like any code has been written yet.
You can look at
http://bitfluxeditor.org/
for a start.
* support for both Mozilla and IE is important.
That's going to give one or two headaches more :-)
Stefano Mazzocchi wrote:
The proposal is about the creation of a content management system for
apache projects, codenamed Doco
snip/
I haven't followed this thread at all, but I've just come upon this site
that might be interesting: http://3d17.org :
People often talk to communities, but how
I spent an afternoon implementing it. It's a complicated beast, and it
uses the intercepted flowscript in a big huge ugly hack... BUT... it
works, which makes me happy :) Check it out at [1] -- please go easy on
it since this is my personal box at home and on my cablemodem. I will
clean it
On Tue, 2003-10-28 at 19:20, Stefano Mazzocchi wrote:
[1] Spoiling Bruno's lonesome hacking cowboy thought train, I just
want to confirm that he actually started working on this.
Yey!!!
He's still in a grumpy friggin' stupid and unstable web browsers and
Javascript as a
Torsten Curdt wrote:
I spent an afternoon implementing it. It's a complicated beast, and it
uses the intercepted flowscript in a big huge ugly hack... BUT... it
works, which makes me happy :) Check it out at [1] -- please go easy
on it since this is my personal box at home and on my
Oh, and I forgot to add (if it isn't terribly obvious) that it's not a Woody widget, but more of a
proof-of-concept to see if I could actually do it :)
Tony
Moving to Cocoon...
A little context: Steven suggested to take a look at
http://kokochi.com:8080/sapience/test.jsp
and implement the above in Doco to avoid automatic crawlers to spam us
thru the editing interface.
On Tuesday, Oct 28, 2003, at 16:26 Europe/Rome, Steven Noels wrote:
Stefano
Stefano Mazzocchi wrote:
snip/
Sounds like a plan to me.
http://james.seng.cc/archives/000145.html seems to be a standalone
Movable Type implementation. Sourceforge is down ATM so I can't check
on the license and usability of the Sapience code.
This looks like a fun problem to solve. I
Stefano Mazzocchi wrote:
On Tuesday, Oct 28, 2003, at 13:10 Europe/Rome, Steven Noels wrote:
snip/
We have seen similar abuse on the Cocoon wiki as well. Rather than
completely offload the burden of moderation to a bunch of people, we
should come up with an upfront facility for blocking
doco has a very precise editing access point. You can
*ONLY* modify xml content.
The unique and only security concern here is defacement.
OK. So not the full site content, just the XML content and images? So then
the exposure is only defacement, page hijacking through a REFRESH
meta-tag,
Noel J. Bergman wrote:
I do agree it would help reducing the risk, but would all moderator's
SMTP server support that?
Ah :-) I was expecting that the moderator would connect *directly* to
moof, in which case only their MUA would have to support SMTP AUTH and SSL.
Out of curiosity, what mail
what mail client do you use that allows you to setup
multiple outgoing servers like this?
Outlook. I have a dozen different accounts, with different servers and/or
identities (@apache, @devtech, @other-organizations). My brother uses
Mozilla, and it supports similar AFAIK.
--- Noel
Stefano Mazzocchi wrote:
2) minimal, efficient and secure workflow (should satisfy board@
security concerns)
FWIW:
Doco came to my mind when finding
http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
/Steven
--
Steven Noelshttp://outerthought.org/
Stefano Mazzocchi wrote:
On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
nah, dude, look: doco has a very precise editing access point. You can
*ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
servlet upload, sql injection, cross-site-scripting, and you next
On Tuesday, Oct 28, 2003, at 11:14 Europe/Rome, Nicola Ken Barozzi
wrote:
Stefano Mazzocchi wrote:
On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
nah, dude, look: doco has a very precise editing access point. You
can
*ONLY* modify xml content. So, changes to .htaccess, CGI
On Tuesday, Oct 28, 2003, at 09:32 Europe/Rome, Danny Angus wrote:
Stefan wrote:
So, adding SSL relay wouldn't hurt, but wouldn't help much either
since
we can't force moderators to have a mail server that accepts that kind
of relay (don't even know if mine does!)
I think what should happen to
On Tuesday, Oct 28, 2003, at 10:11 Europe/Rome, Steven Noels wrote:
Stefano Mazzocchi wrote:
2) minimal, efficient and secure workflow (should satisfy board@
security concerns)
FWIW:
Doco came to my mind when finding
http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
Can I be anal
Stefano Mazzocchi wrote:
Doco came to my mind when finding
http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
Can I be anal for a sec?
LOL. Sure, as long as you wipe properly afterwards, no problem here. :-)
cool, but what do we do with it?
Well, since people had to come up with
In order to get myself into the Doco discussion I have created a Wiki
page at (I was busy moderating emails for lenya-dev ...)
http://wiki.cocoondev.org/Wiki.jsp?page=Doco
where I have compiled Stefano's original proposal and added issues from
the various email threads.
Would be nice if
On Tuesday, Oct 28, 2003, at 13:10 Europe/Rome, Steven Noels wrote:
Stefano Mazzocchi wrote:
Doco came to my mind when finding
http://kokochi.com:8080/sapience/test.jsp in Hippo's blog.
Can I be anal for a sec?
LOL. Sure, as long as you wipe properly afterwards, no problem here.
:-)
cool, but
Stefan wrote:
So, adding SSL relay wouldn't hurt, but wouldn't help much either since
we can't force moderators to have a mail server that accepts that kind
of relay (don't even know if mine does!)
I think what should happen to ensure this level of integrity would be that
moderators
Stefano Mazzocchi wrote:
That is a *very good point* and I think you are perfectly right: we
should put it into Doco. Any idea on how to do it?
*blush*
In my layman's thinking, I would envision this as some special Woody
widget which generates a random image for display, makes it available
On 29.10.2003 00:00, Noel J. Bergman wrote:
what mail client do you use that allows you to setup
multiple outgoing servers like this?
Outlook. I have a dozen different accounts, with different servers and/or
identities (@apache, @devtech, @other-organizations). My brother uses
Mozilla, and it
On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:
He's not questioning whether it's encrypted. His point is, doco sends
an email to an address, and you respond. It gives very little
control,
even if there is a compromise.
AIUI, the proposed solution would allow anyone to
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2003 6:06 AM
To: James Developers List
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; lenya-
[EMAIL PROTECTED]
On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:
On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:
nah, dude, look: doco has a very precise editing access point. You can
*ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
servlet upload, sql injection, cross-site-scripting, and you next
favorite attack will NOT
Vadim Gritsenko wrote:
Upayavira wrote:
Joerg Heinicke wrote:
...
Is offline/online still an issue?
It is for me. Much of my Cocoon work (and some of my mailing list
reading) is done on a train to and from work, without net access. I
am equally concerned about whether I'll be able to work on
The proposed workflow institutionalizes RTC,
RTC?
Review Then Commit. As opposed to Commit Then Review. I think there are
other variations on the phrase floating around.
Perhaps we could require SMTP AUTH over SSL for the
moderators?
Hmmm, I don't really see how this would help. The
Vadim Gritsenko wrote:
Geoff Howard wrote:
The one part that stands out to me as a weak link is the reply
vs. reply to all mechanism. It seems prone to human errors and to
things like vacation messages. How would conflicts be handled (one
person rejects and one approves)?
...
I agree that
Noel J. Bergman wrote:
don't know, maybe I'm missing something, but what do you think a
possible attack could be?
I don't consider any traffic across the Internet to be secure unless
encrypted. Why do you use SSH instead of telnet if packets are secure?
He's not questioning whether it's
He's not questioning whether it's encrypted. His point is, doco sends
an email to an address, and you respond. It gives very little control,
even if there is a compromise.
AIUI, the proposed solution would allow anyone to edit content, and
contribute it as a patch. Content could include
Stefano Mazzocchi wrote:
Steven Noels wrote:
Stefano Mazzocchi wrote:
snip what=stuff about wiki vandalism and annoyance/
Different would be to have f**k [insert your favorite public figure
here] or child pornography passing thru the system, but in order to
happen, the chain of events
On Friday, Oct 24, 2003, at 15:57 Europe/Rome, Steven Noels wrote:
Stefano Mazzocchi wrote:
In the entire history of the wiki, we had only a few cases of severe
vandalism on our wiki.
Please don't over-generalize, Stefano. We have weekly 'annoyances' on
the Cocoon Wiki ATM, but some people
Joerg Heinicke wrote:
...
Is offline/online still an issue?
It is for me. Much of my Cocoon work (and some of my mailing list
reading) is done on a train to and from work, without net access. I am
equally concerned about whether I'll be able to work on the 'doco'
system myself without net
Le Samedi, 25 oct 2003, à 17:56 Europe/Zurich, Upayavira a écrit :
Joerg Heinicke wrote:
...
Is offline/online still an issue?
It is for me. Much of my Cocoon work (and some of my mailing list
reading) is done on a train to and from work, without net access. I am
equally concerned about whether
Bertrand Delacretaz wrote:
Le Samedi, 25 oct 2003, à 17:56 Europe/Zurich, Upayavira a écrit :
Joerg Heinicke wrote:
...
Is offline/online still an issue?
It is for me. Much of my Cocoon work (and some of my mailing list
reading) is done on a train to and from work, without net access. I
am
On Saturday, Oct 25, 2003, at 00:37 Europe/Rome, Geoff Howard wrote:
This is still much easier than the current workflow with applying a
patch, committing to CVS, and so on, but less error prone than the
above approach.
Again, does anyone really think the choice of this method should delay
On Saturday, Oct 25, 2003, at 16:43 Europe/Rome, Joerg Heinicke wrote:
On 24.10.2003 15:47, Stefano Mazzocchi wrote:
Joerg Heinicke wrote:
We should at least use the body with an explicite accept and
reject in it. This can't be done by accident, while it can happen
for sending a mail.
But why
On 26.10.2003 01:49, Stefano Mazzocchi wrote:
We should at least use the body with an explicite accept and
reject in it. This can't be done by accident, while it can happen
for sending a mail.
But why not at least explicite accept/reject in the subject or the
body of a mail?
saves you a
On Saturday, Oct 25, 2003, at 00:39 Europe/Rome, Noel J. Bergman wrote:
Stefano,
+1
Looks like a good plan that takes the ForrestBot idea, builds on it,
integrates other things, seems secure and scalable, provides the
opportunity
for anyone to help write documentation, but provides multiple
Joerg Heinicke wrote:
On 26.10.2003 01:49, Stefano Mazzocchi wrote:
We should at least use the body with an explicite accept and
reject in it. This can't be done by accident, while it can
happen for sending a mail.
But why not at least explicite accept/reject in the subject or
the body of a
Upayavira wrote:
Joerg Heinicke wrote:
...
Is offline/online still an issue?
It is for me. Much of my Cocoon work (and some of my mailing list
reading) is done on a train to and from work, without net access. I am
equally concerned about whether I'll be able to work on the 'doco'
system
Stefano wrote
c) the email will have reply-to set to the allow action and
a continuation ID. and will have the CC: header set to reject with
the continuation ID. So, by replying to the email
d) by hitting reply, the workflow will approuve the changes
e) by hitting reply to
Joerg Heinicke wrote:
Stefano wrote
c) the email will have reply-to set to the allow action and
a continuation ID. and will have the CC: header set to reject with
the continuation ID. So, by replying to the email
d) by hitting reply, the workflow will approuve the changes
e)
Stefano Mazzocchi wrote:
First of all, sorry for the massive cross-post, but I think it is going
to be a great opportunity for all the communities involved to show off
their potentials with the apache infrastructure.
The proposal is about the creation of a content management system for
apache
Joerg Heinicke wrote:
Stefano wrote
c) the email will have reply-to set to the allow action and
a continuation ID. and will have the CC: header set to reject with
the continuation ID. So, by replying to the email
d) by hitting reply, the workflow will approuve the changes
e)
Stefano Mazzocchi wrote:
In the entire history of the wiki, we had only a few cases of severe
vandalism on our wiki.
Please don't over-generalize, Stefano. We have weekly 'annoyances' on
the Cocoon Wiki ATM, but some people happen to clean them up sooner
rather than later. I know the Wiki
Stefano,
+1
Looks like a good plan that takes the ForrestBot idea, builds on it,
integrates other things, seems secure and scalable, provides the opportunity
for anyone to help write documentation, but provides multiple points
oversight. The proposed workflow institutionalizes RTC, but the
First of all, sorry for the massive cross-post, but I think it is going
to be a great opportunity for all the communities involved to show off
their potentials with the apache infrastructure.
The proposal is about the creation of a content management system for
apache projects, codenamed Doco
Hi Stefano,
I think the overall concept for this project is pretty cool and very
well thought out.
The one part that stands out to me as a weak link is the reply vs.
reply to all mechanism. It seems prone to human errors and to things
like vacation messages. How would conflicts be handled
56 matches
Mail list logo
