Re: [Zope3-dev] Core topic in Collector
Jim Fulton wrote: Steve Alexander wrote: I'd be happy using launchpad too. The last link points to a discussion that didn't have any decision in the end. I wouldn't go as far as abandoning the old collector data. Then I think we should stick with the current collector unless someone comes forward to do the work of moving the data, or unless we decide we don't need to. ... As many of you know, I'm manager of the Launchpad project at Canonical. I hereby offer the services of a member of the Launchpad team at Canonical to write Collector code if necessary in order to get an export of bugs from the Collector in a format that can be imported into Launchpad, to import said bugs into a demonstration server of Launchpad so we can check that the data conversion is good enough, and to do an actual import into the Launchpad production database, and to do this during January 2007. In return, I want a commitment that we'll use Launchpad for bug tracking for 6 months. (The bug data will be available in a documented XML format if y'all decide that Launchpad isn't for you, and you want to move to something else after this time.) I also want to give the Launchpad developer a single point of contact in the Zope community who will make decisions about any questions around mapping the semantics of Collector issues into Launchpad bugs, or lead discussions on the mailing list about this if necessary. There are a few Launchpad developers in the Zope developer community, so I think there's a good communication channel there. Nonetheless, I would also like to offer the Zope Foundation Board phone and online access to the Canonical 24/7 support office for getting a quick response on any critical issues that are affecting use of Launchpad, while the Zope project is using Launchpad as its bug tracker. I'd appreciate a decision on this offer before Christmas, and preferably sooner, so I can schedule the time before I leave on vacation. Thanks for this very generous offer. We've discussed this on the Zope Foundation Board and we unanimously accept your offer. Thank you (and the rest of the Board) for a swift decision. I'll make scheduling arrangements. I assume that this pertains to Zope 3 only. I'd love to move the ZODB issues to Launchpad, but that would require converting at least some of the Zope collector as well. I think that once we've figured out the right way to move one Collector, we can straightforwardly apply that to any others, as needed. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Launchpad offer (Was: Core topic in Collector)
There are a few Launchpad developers in the Zope developer community, so I think there's a good communication channel there. Nonetheless, I would also like to offer the Zope Foundation Board phone and online access to the Canonical 24/7 support office for getting a quick response on any critical issues that are affecting use of Launchpad, while the Zope project is using Launchpad as its bug tracker. Yay! I guess that would be done by our single point of contact, right? I spoke to Jeff who runs the support department. What we usually do for commercial support is that two people in the customer's organisation are nominated as support contacts. So, for Zope, I expect the Zope Foundation Board would nominate one or two people as the support contacts for using Launchpad. The single point of contact for checking the quality of the bugs imported into the demonstration server can be a different person. One question popped up for me: Are we talking about the Zope 3 collector or all collectors on zope.org? Launchpad seems to give us even more benefit if we switched all collectors over, because we would get the upstream management capability. Right, the ability to have a bug filed on, say Zope 3, but then later retargetted to ZODB. However, this is the zope3-dev list and I'm not sure we could decide this for Zope 2 and ZODB. OTOH we could make a first step by switching with Zope 3 and let everybody else join us in the mid-/longterm. I can also imagine that extending the discussion to CMF, Zope 2 and the ZODB right now would render us inable to get to a decision within the next days. My own conclusion on this is therefore that we should talk about the Zope 3 collector only. I'm fine with this. Once the programming work is done, and we have a good mapping of the bugs' statuses in the Collector to the bug statuses in Launchpad, it will be straightforward to move the data from other Zope-related projects that use Collectors. So, the big issue there is seeing if this is a move that is supported by the community of people developing on these projects. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On a small aesthetics side, I find Launchpad's side bars incredibly distracting, and I don't like looking at the page because it feels like there are too many things vying for my attention and I have a hard time really reading the text in front of me. The content gets squished. And then I find myself looking at all of these links and buttons around the page trying to figure out what has the information I'm interested in. The sidebar on Zope.org bothers me in the same way when I try to read the Zope 3 wiki - but Zope.org feels nowhere near as noisy as Launchpad. I'm sure their tools are great, and the hosting service is a good feature. I understand what you're saying about the Launchpad UI, and I agree with it. There's a significant re-design of the Launchpad UI underway right now that ought to address many of these issues. It won't be on the live site for a couple of months, though. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. We're fine with you creating lots of projects, and actually Launchpad is meant to support working that way. The way the bug tracker is set up, it is straightforward to transfer responsibility for fixing a bug from one project to another, or to indicate that there is a shared responsibility. For example, I might file a bug on Zope, but really it is a bug in zc.buildout. Rather than filing a new bug elsewhere, whoever triages the bug can reassign it to zc.buildout without losing comments or history or subscribers. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
I would suggest to register the layers like skins using a ILayerBrowserType interface: interface interface=.interfaces.I18NFeatures type=zope.publisher.interfaces.browser.IBrowserLayerType / It is simple to create a zcml directive specifically for registering a layer. If there is a good reason to register layers, then I think there should be a zcml directive for it. Of course, it may be that there's not really a good reason for registering layers. 2. I liked the naming ISkinType and ILayerType much more (instead of IBrowserSkinType/ IBrowserLayerType), because this browser-specific differentiation is already given by the package hierarchy and those ILongCamelCaseWordingsThatTriesToExplainEverything are hard to type and at the end they confuse newcomers even more than the simple ones. Please keep the naming also simple and stupid like the skinning simplification itself :) I don't feel strongly about this at all. It was mostly Steve's idea and I took his suggestion as it adds some conherence (IBrowserRequest, IBrowserResponse, IBrowserLayerType, ...). It would be up to Steve to defend it, for all I care we can use the shorter forms. Who will use these interfaces? In what parts of the code will they be present? I think these marker interfaces are used only in infrastructure code to do with setting up layers and skins. In this case, they will not be typed often, and will not even be read often. So, I think it is more important that the name be clear than the name be short, so that it can be understood quickly upon reading it. Two good points I agree with. I wanted to write a similar response as 1., but did not have a good argument. Dominik just gave it. I think it is important to keep a registry of all layers, especially for TTW development, an area I really want to put some effort in for 3.3. Why do you need a registry of all layers? What use-cases drive this requirement? Maybe you just need to be able to look them up? Thanks, I guess this is a good use case. The good thing is that the whole ILayerType thing can be *optional*. This is important to me. The core of a publisher-with-layers can be based on just a request's interfaces. No need for extra complexity or infrastructure. It should be possible to strip a use of Zope 3 down to this level. The 'type' argument of browser:page et.al. won't require an ILayerType interface; any interface will do as long as it is or extends IBrowserRequest. This is important too. Only if you want your layer interface to show up for TTW view registration, you'll need ILayerType so that it shows up in the Browser Layers vocabulary and thus among the list of selectable layer interfaces. I strongly support this being an optional feature; a price you pay only if you care about TTW stuff. That said, I still think that in the long term, local registration should not be done TTW. So this optional notion of ILayerType might not be necessary in the future after all. For filesystem-based development I don't find any compelling usage for it at all. Me too. So, if there are no other comments on this proposal, I will update it with your latest suggestions and get started on the implementation (on a branch, of course). -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
It is simple to create a zcml directive specifically for registering a layer. If there is a good reason to register layers, then I think there should be a zcml directive for it. I disagree. Just because it is simple to create new ZCML directives doesn't mean we don't have to. The less special ZCML directives there are, the less people need to learn and the more people can reuse reoccurring idioms. That's a good thing. If we can pass on architectural simplifications to the developer who's writing Python and ZCML, we should do that. I see what you're saying. I didn't explain where I'm coming from. I think that the ZMI is really a separate product than the core of Zope 3. This is a controversial position to hold. From that position, I think that if the ZMI product wants to define its own ZCML to make doing ZMI-related things easy, then it should. I understand from this discussion that registering layers is needed only for certain ZMI things, to be implemented later on. So, I guess the ZCML will be implemented later on, or not implemented later on. In either case, later on. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
I understand from this discussion that registering layers is needed only for certain ZMI things, to be implemented later on. So, I guess the ZCML will be implemented later on, or not implemented later on. In either case, later on. I disagree. The layers are registered now. You rip them out now, just so I have to add them later again? That sounds dubious to me. Earlier, you were saying that you didn't see a need for a specific zcml statement to register layers, so your statement above confuses me. I'm proposing a consideration, later on, of special zcml to register layers for use in the ZMI. In addition, I'd like to say that I believe that it is important to keep things that are just for the ZMI separate from the core, where they add complexity to the core. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Rename principal to participant
Interesting. It looks to me like you're calling a User object what the CMF calls a Member. Sure. Does the CMF have any users who aren't members? Would you say that the existence of such a concept in PAU should make principal annotation a unnecessary, if not even deprecated? I don't really see the point of principal annotation as a special thing. Being able to annotate things is good. I'm not sure principals should be a special case either way. Can you annotate permissions? I don't think systems should be built relying on being able to annotate principals. That sounds kind of implicit. I'd rather see a first class User concept. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Rename principal to participant
If not that, we can at least make the weaker case that no Zope 3 *UI* user (whether it's the ZMI or something built on top of it) ordinarily should have to know about 'principals'. I agree with that. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Rename principal to participant
Note that such user objects (or group objects) in applications are frequently content objects and are accessible through content space. I think in Zope 2 terms this entity may be called 'member'... In Launchpad, we have a Person table in the database. Data from there are converted into objects, and used in the application. These are Person objects. The user for a given request is a Person object. It is the Person object representing the user who is identified as using the system in that thread at that time. Here we go... some docs from the Launchpad wiki: https://wiki.launchpad.canonical.com/UserPersonPrincipal The wrong way to go about this is to store user information somewhere under ++etc++, Sorry for the crudeness, but ++etc++ makes me want to barf. Have an etc stuff web server running on a different port, with a different root traversal resource. Don't make it part of the web app that you show to users. You'll just want to turn it off later on. as that isn't content space in my book and I don't want to expose end users (that need to do user management sometimes) to anything in ++etc++. (it's okay to store low-level user information in ++etc++, as at is now, but no extensible user info with extra information like email addresses, etc, I think). -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Rename principal to participant
Philipp von Weitershausen wrote: Martijn suggests to just use user. I can live with that. The reason why I didn't propose that is because I thought people still valued the abstraction of a principal as opposed to the physical person. I don't need it and all those Unix users out there don't seem to need it either... Dmitry Vasiliev wrote: +1 on user. Actually for Russian translation I've used user anyway since I didn't find another good translation for principal. I'm -1 on user. In Launchpad, the concepts of User and Principal are quite different. For example, a principal that represents a particular user accessing the web application is different from the principal that represents that same user accessing Launchpad via gpg signed email. In Launchpad, request.principal is not used by the application programmers. It is used only by the authentication, authorization and publication machinery. The machinery looks up a Person (an application domain object) for the current principal (the participant, if you will) and makes this available to application code. So, application code deals with an application-level object, not some security system construct. Maybe in some simple systems it is good to conflate the concepts of user and principal. Making the principal available from the request in zope3 encourages this. But, I think that it is not good application design, and it does not make for clear abstractions. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Rename principal to participant
Shane Hathaway wrote: Steve Alexander wrote: In Launchpad, request.principal is not used by the application programmers. It is used only by the authentication, authorization and publication machinery. The machinery looks up a Person (an application domain object) for the current principal (the participant, if you will) and makes this available to application code. So, application code deals with an application-level object, not some security system construct. It sounds like you're saying only the security machinery should know about principals, and that everything else deals with users. If so, it should not be necessary for any Zope 3 developer to learn about principals unless they are writing security machinery. Is that right? You need to know about principals if you are writing security machinery, or if you are writing the thing that maps principals to whatever passes for users in your application. What typically happens is, the request contains credentials. The principal represents the fact that those credentials have been checked and found to be ones that the system knows about. It also represents the type of credentials, for example, how much you trust them. This in turn maps to the concept of a user accessing your system. credential - principal - user The Zope 3 framework can take care of the credentials and principals. The users are application-specific. A content management system for Zope 3 would have its own concept of what a user is, but still use the Zope 3 concepts and implementations of principal and credential. A room booking and timetabling system may have a different concept of a user, as a user may well be a specific instance of a content object such as a person (who is a bookable resource). -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Rename principal to participant
I think so too. But I whould not try to explain a PAU (pluggable authentication utility) without to use the word principal. I think using the words user or participant for a principal in this case is not a good idea. Perhaps the scope of the PUA can be extended to have a plug-in factory for User objects, and to make the current User easily available inside page templates and other presentation code. People who wish to use[1] the PUA would define their own User class, which could be as simple as taking the principal id, but would often be more complex according to the needs of their application. -- Steve Alexander [1] Desperately trying to avoid using the term user there. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: TALES namespace names cannot contain '-'
Yes, unless Zope 3 TALES is very unlike Zope 2 TALES. We deliberately
restricted the syntax of namespaces to be valid variable names in Python
(and most other languages). This allowed, for example, direct use of
the name of a namespace as a function in a Python expression:
python:x and path('%s/%s' (base, x))
I don't understand this example.
I see that there's meant to be a '%' operator in there.
But, I don't understand what use of the name of a namespace as a
function in a Python expression means, and I see only the function
'path' above.
--
Steve Alexander
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] TALES namespace names cannot contain '-'
Hi,
I recently wanted to make a TALES namespace called 'enum-value' for use
in Launchpad development.
I found that this didn't work, because only the characters [a-zA-Z0-9_]
are allowed. You can find the regex on line 27 of
zope/tales/expressions.py.
namespace_re = re.compile('(\w+):(.+)')
I propose to extend this to allow the '-' character too.
Any objections to this?
Are there any other characters that should be included?
Do any specifications need changing?
--
Steve Alexander
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
