Re: [Framework-Team] Re: Suggestion for adding Usecase information
On 24 dec 2007, at 04:27, Hanno Schlichting wrote: Danny Bloemendaal wrote: After having waded through a big pile of plips I often (as a less technical oriented member) had problems determining what the actual usecase was that it was trying to solve. I would like to suggest (when thechcnically possible) to add such a section in a plip. I'd like to see a real-world usecase example (for the less technical ppl) what the plip has to solve/support/whatever. Something like: Suppose someone wants to write a product that supports this or that. Right now he has to do this or that to do this but with this plip in place he only has to do such or so. Right now, the Motivation section isn't exactly that. In most cases, the author immediately dives into technical details. I think it would help to have this addition? Or am I talking nonsense here? +1, I think we have been bad both on the side of use-case centric and integrator targeted information. So what is needed? I think that only an extra header in the boilerplate text for a plip would be enough (and stress that writes fill it in of course). ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Suggestion for adding Usecase information
Danny Bloemendaal wrote: On 24 dec 2007, at 04:27, Hanno Schlichting wrote: Danny Bloemendaal wrote: After having waded through a big pile of plips I often (as a less technical oriented member) had problems determining what the actual usecase was that it was trying to solve. I would like to suggest (when thechcnically possible) to add such a section in a plip. I'd like to see a real-world usecase example (for the less technical ppl) what the plip has to solve/support/whatever. Something like: Suppose someone wants to write a product that supports this or that. Right now he has to do this or that to do this but with this plip in place he only has to do such or so. Right now, the Motivation section isn't exactly that. In most cases, the author immediately dives into technical details. I think it would help to have this addition? Or am I talking nonsense here? +1, I think we have been bad both on the side of use-case centric and integrator targeted information. So what is needed? I think that only an extra header in the boilerplate text for a plip would be enough (and stress that writes fill it in of course). I think this fits well inside the "Motivation" box we already have. What's needed is a framework team that proactively asks people to fill in that information when submitting PLIPs, should it be insufficient. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Suggestion for adding Usecase information
On 24 dec 2007, at 11:24, Martin Aspeli wrote: Danny Bloemendaal wrote: On 24 dec 2007, at 04:27, Hanno Schlichting wrote: Danny Bloemendaal wrote: After having waded through a big pile of plips I often (as a less technical oriented member) had problems determining what the actual usecase was that it was trying to solve. I would like to suggest (when thechcnically possible) to add such a section in a plip. I'd like to see a real-world usecase example (for the less technical ppl) what the plip has to solve/support/whatever. Something like: Suppose someone wants to write a product that supports this or that. Right now he has to do this or that to do this but with this plip in place he only has to do such or so. Right now, the Motivation section isn't exactly that. In most cases, the author immediately dives into technical details. I think it would help to have this addition? Or am I talking nonsense here? +1, I think we have been bad both on the side of use-case centric and integrator targeted information. So what is needed? I think that only an extra header in the boilerplate text for a plip would be enough (and stress that writes fill it in of course). I think this fits well inside the "Motivation" box we already have. What's needed is a framework team that proactively asks people to fill in that information when submitting PLIPs, should it be insufficient. I don't agree entirely. Motivation doesn't have to b a description for the usecase. Motivation is very general and can be a technical story only. A usecase is a 'normal'-people's description of what it tries to solve. It's almost like a scenario or a scriptive way to describe things. Motivation ís being used right now but hardly ever in the scenario/use-case kinda way. I don't think it is good idea to 'correct' people if they didn't use Motivation is this way. It's better to have them write it from the start. Danny ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Suggestion for adding Usecase information
Danny Bloemendaal wrote: So what is needed? I think that only an extra header in the boilerplate text for a plip would be enough (and stress that writes fill it in of course). I think this fits well inside the "Motivation" box we already have. What's needed is a framework team that proactively asks people to fill in that information when submitting PLIPs, should it be insufficient. I don't agree entirely. Motivation doesn't have to b a description for the usecase. Motivation is very general and can be a technical story only. A usecase is a 'normal'-people's description of what it tries to solve. Right. And IMHO no PLIP can be accepted if it doesn't address any real world use cases, hence that should be the core of the motivation. It's almost like a scenario or a scriptive way to describe things. Motivation ís being used right now but hardly ever in the scenario/use-case kinda way. Yep. We should be better at it. I don't think it is good idea to 'correct' people if they didn't use Motivation is this way. It's better to have them write it from the start. Let me put it another way - I'd rather not have to make changes to PSC and deal with releases and migrations when we have a field that in one interpretation already meets the requirement. You can create however many fields you want with whatever titles you want - at the end of the day, it comes down to whoever fills the form in and what guidance they receive. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: preliminary results for PLIP selection & call for votes!
On Dec 23, 2007, at 3:14 PM, Sidnei da Silva wrote: To be clear, I believe the only -1 vote on #187 was primarily due to some concerns about the shortage of detail in the PLIP text. A concern I share. I'm hoping Sidnei fleshes out the details soon. :-) I would gladly answer any questions. The PLIP doesn't have much detail because there ain't much to be detailed. The branch achieves the first bullet under 'Proposal', and the third bullet was addressed and released in a Zope release. The second bullet has resulted in some research and I'm waiting for confirmation from Nate Aune that the proposed fix for it works. I have not addressed versioning because I didn't know there was any concern about it. I saw the comment #3 but my assumption was that whoever implemented versioning did it in such a way that it would interact correctly with WebDAV, but did not have the time to verify such assumption. Feel free to ask more questions... Thanks Sidnei, What is the proposed (unconfirmed) fix for the second bullet (the OS X resource fork issue)? Ric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: preliminary results for PLIP selection & call for votes!
On Dec 24, 2007 1:15 PM, Ricardo Newbery <[EMAIL PROTECTED]> wrote: > What is the proposed (unconfirmed) fix for the second bullet (the OS > X resource fork issue)? Here it is, I would be glad if someone can test and confirm this works: """ I've found an article describing a hack using Apache rewrite rules, but I believe we can get something going in pure Zope if you can give this a try and it works fine. The example setup is here, however the guy mentions that using 'forbidden' prevents creation of new files *at all*: http://www.netmojo.ca/blog/2007/05/03/subversion-webdav-osx/#solution I found mention in other WebDAV server implementations that returning a 404 might please Finder just fine, though it would be better to use that Finder configuration as even if the server rejects those files, Finder still tries to send it, so configuring Finder properly will make it faster. So, from that guy's example, it looks like the correct configuration would be to remove this part: # Deny OSX dot files RewriteEngine On RewriteCond %{REQUEST_METHOD} ^PUT$ RewriteRule .DS_Store - [F] RewriteRule .Trashes - [F] RewriteRule .TemporaryItems - [F] RewriteRule ._.* - [F] And instead list those filenames in the RedirectMatch directive below: # Fix broken Windows XP RedirectMatch 404 ^/(MSOffice/|_vti_bin/|_vti_inf.html$) So the final configuration would look somewhat like: RedirectMatch 404 ^/(MSOffice/|_vti_bin/|_vti_inf.html$|.DS_Store|.Trashes|.TemporaryItems|._.*) If you can give that a try, and it works for you, then we can look at implementing this in Zope, with a configuration directive to selectively disabling it in zope.conf. """ -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: preliminary results for PLIP selection & call for votes!
Thanks again Sidnei, [note to framework list: let me know if I should take this discussion off list] Maybe I'm missing something but there doesn't seem to be any reason to return a 404 (Not Found) or 403 (Forbidding) response. Why not just silently discard the offending files, along with the configuration directive option? Should be simpler to code. Ric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: preliminary results for PLIP selection & call for votes!
On Dec 24, 2007 6:36 PM, Ricardo Newbery <[EMAIL PROTECTED]> wrote: > Thanks again Sidnei, > > [note to framework list: let me know if I should take this > discussion off list] > > Maybe I'm missing something but there doesn't seem to be any reason > to return a 404 (Not Found) or 403 (Forbidding) response. Why not > just silently discard the offending files, along with the > configuration directive option? Should be simpler to code. I have tried that approach and it failed in the past. If we behave like the file has been succesfully created but just plain discard it, Finder will expect it to be there, and if it get a 404 for a file that was just created and it really expected to exist, it fails miserably. Of course that could have changed in later versions of Finder. Sending the 404/403 upfront is a saner and simpler approach which doesn't break expectations on either side, IMO, and is more likely to work. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: preliminary results for PLIP selection & call for votes!
Ricardo Newbery wrote: Thanks again Sidnei, [note to framework list: let me know if I should take this discussion off list] No problem with me. You might want to consider cross-posting or moving to plone-devel depending on the audience you want to reach. Just my 2 cents, Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Official submission: PLIP 184, 200, 203 and 204
Martin Aspeli wrote: [..] Cheers, and merry Christmas :) Thanks for all your contributions and Merry Christmas, Raphael Martin [1] http://dev.plone.org/plone/browser/review/optilude-plipathon-184-200-203-204/REVIEW-NOTES.txt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team