Re: [s-d] proposal parser

[Antonio Dolcetta <antonio.dolcetta@xxxxxxxxx>]

Daniel Lepage wrote:
> 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.

I'm planning to eventually use xml internally, but having people 
actually write well-formed xml is not as easy as it sounds, for instance 
what you wrote before is not well-formed xml, and if it's not 
well-formed it's just random < and > peppered text, so where's the point ?
I do agree that BEGINPROPOSAL and ENDPROPOSAL are suboptimal, it's 
currently just a quick hack and those were the first things that I came 
up with. XML fails at the other end, we need something in between.

> 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 agree on this

>>>> 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.

even better than that would be pgp authentication, I was hoping we could 
avoid that, because I hate using it, but it's not too complicated to 
code. Still it doesn't do much for the title problem, what else can we 
use to understand if a player is amending a prop or making a new one ?

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

how can spammers exploit something that reads a mailing list ? if they 
can reach it, they have already reached the mailing list so it's not 
like it can be much worse no ?

>> 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.

this is non-compatible with the "read the mailing list" option, messages 
that do not contain a proposal are ignored of course. so you cant get an 
ack if it doesn't work. not getting the ack is the only version of a 
non-ack i can think of

>>> 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.

mildly irritating, unless we can provide some added value, like printing 
only the diff between versions in case of a revision, that would be 
mildly useful and maybe less irritating

> 
>>> 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.
> 

well, how many times do you want to do that ?
i'm not saying it's perfect, and the system can still be overridden 
manually of course. it aims to be a way to automatically track proposals 
and revisions to lighten the load on the admin. It also wants to be 
fairly simple, so that you can easily predict if it's going to work or 
not, that way if you know you need to write a proposal that won't be 
parsed, you can just ask the admin to add it manually as we have always 
done.



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