Re: [s-d] proposal parser

[Daniel Lepage <dpl33@xxxxxxxxxxx>]

On Jan 22, 2007, at 8:49 PM, Antonio Dolcetta wrote:

>
> On 22 Jan 2007, at 22:21, Daniel Lepage wrote:
>
>>
>> On Jan 22, 2007, at 1:02 PM, Antonio Dolcetta wrote:
>>> I've written a very basic (read: horrible) proposal parser.
>>> you start proposals by writing BEGINPROPOSAL and end them with
>>> ENDPROPOSAL, each proposal must have a title, enclosed between
>>> STARTTITLE ENDTITLE
>>
>> What if I want to use the word "ENDPROPOSAL" in the course of my
>> proposal?
>
> yes, that would break it,
> easy solution: don't do it
> hard solution: think up a way to dynamically figure some delimiters,
> ideas ?

"Don't do it" could be bad - what if we want to make it a rule that  
you MUST delimit your proposals this way? The proposal to add that  
would need all sorts of ugliness so that it could mention the words  
without actually using them.

How about using XML instead of just text?
<BEGINPROPOSAL>
propity prop prop
<ENDPROPOSAL>

All sorts of parsers for that exist already, and they all know how to  
do things like escape dangerous text. Also, with XML the system would  
generalize immediately to other documents.

The downside is that XML is kind of a pain to type sometimes, but  
then again it's no worse than having to type non-XML delimiters  
whenever we make props.

We should add a rule allowing wiki syntax in props, btw. Right now  
the important thing in any rule or proposal is the raw text, hence  
each prop being shown verbatim on the wiki. However, I'd love a  
clause allowing wiki syntax so that I could include e.g. a table in  
the body of a rule without trying to get ascii tables to format on  
the wiki.

>>> i was wondering if it's really needed to password protect stuff, I
>>> could
>>> just read the sender mail address and match that with the latest
>>> proposal with the same title.
>>> if that was from a different address the new one gets discarded.
>>> Yes, i know It's easy to forge mail headers, but we can already do
>>> that,
>>> no ?
>>
>> What if somebody has two email addresses? Also, nothing currently
>> prohibits two props with the same title; it sounds like this script
>> would foul up in that case.
>
> yes, it would require ad hoc legislation

Whereas with passwords, you'd just include your password at the top  
and the system would know who you were.

Also, it adds a little more protection from spammers accidentally  
stumbling onto the system.

>>> I was also thinking, instead of having people send proposals to a
>>> special address we could simply subscribe the bot to the mailing  
>>> list
>>> and have it work automatically, that would be nice.
>>
>> It would be nice as long as there were some clear indication when
>> something goes wrong. For example, if I start a message with
>> STARTPROOSAL, everyone will get the message and see that I made a
>> proposal, but it wouldn't show up on the page because the script
>> wouldn't recognize it.
>>
>
> i was thinking that the script would send an ack mail to the list, so
> you would notice something is wrong if you don't see it

I'd want feedback to me, at least, even if it didn't work. That way I  
can distinguish between "my proposal was flawed" and "the list is  
temporarily down" without sending test messages to the list.

>> Also, having people send to a special address has the advantage that
>> id numbers can be assigned immediately and will show up in the
>> resulting message. Right now, we see the proposal when the author
>> sends it, and then we learn its ID number when the admin assigns one.
>> With the script, the number is assigned immediately, but we can't see
>> it unless the script sends another message announcing the number.
>>
>
> yes, that was the main reason for sending an ack

But now we're generating two messages for every proposal and every  
revision; that's just irritating. I suppose we could use the spoon- 
notices for the acks, so at least they'd be to separate lists.

>> A third problem is robustness in the face of unexpected messages -
>> what if I reply to somebody's prop message but forget to remove their
>> proposal in the reply text? Will the system register that as a new
>> proposal, made by me and with lots of >s in the text?
>>
>
> obviously lines starting with > would not get parsed
> also the kind of quoting google mail uses has to be recognized

But then we once again have the problem that maybe I want a > in my  
prop. For example, if I'm pasting a quote from the email list into a  
comment.

-- 
Wonko

_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss