[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote: Martin Aspeli wrote: Anyway - I hope these perspectives are useful. I'm certainly not disagreeing with what you're saying or with the direction you're pointing out. I think we just need be mindful that there were some good things about the past approaches as well as problems (not that you're not). I think we're in strong agreement. I think we need both the Framework and the apps that use the Framework, including Zope2/Plone-style pluggable apps. I think we need to keep these efforts somewhat distinct though. I'd love to see projects that focus on building killer apps on top of the Zope 3 framework. I just want people to understand that the application != the framework. As a non-developer observer, I'm +1 with Jim's discussion. Martin, you're right that developer influx should be the key goal, and that (a) simpler entry points like Grok and (b) killer apps are the way to get to that goal. I don't think the killer app, though, should be the responsibility of the Zope project. More bluntly, I don't think it's fair to tell the Zope 3 core team to do it: they are more interested in machinery, they don't need to do it for their jobs, and are already giving us plenty. Let's decrease the responsibilities of the core. (Note: 3 years ago I lobbied heavily for the Zope 3 to keep the TTW dream alive, but my thinking was flawed.) Couple of interesting side points: 1) It took me a couple of years to realize Zope 3 wasn't aimed at me, then another year to realize this was a good thing. [grin] Higher-level systems need industrial-strength stuff. People like me are looking for quick hits, not industrial-strength. I later hoped, though, that Zope 3 would make it easier to build something aimed at me, like Archetypes or possibly Grok. 2) Jim pointed out something earlier in the thread, and I think Suresh might have alluded to it, but the "OFS" (including TTW stuff and ZClasses) was interesting and useful and a "killer app". But they existed not because the community that sprung up after Zope's open source-ing were willing to build it. Instead, that software and that audience were inherited from Principia, which most certainly didn't want to sell a platform. We were aiming at end-user power developers, going so far as to hide (gasp!) Python. An interesting conclusion: the current-core-team might not have built the "OFS". And yet, the TTW stuff was galvanizing to some audience, and part of the sex appeal that helped Zope take off. My lesson from this: to succeed, you have to have both a good idea and people ready to commit to it. Thus, telling the Zope 3 core team to own and distribute the killer app is neither realistic nor fair. Move Zope 3 to its natural turf and collaborate with folks that feel passionate about other turf. Application != the framework. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 lacks Ajax capability?
Jeff Rush wrote: Benji York wrote: Zachery Bir wrote: I think Benji's commenting on the fact that you're creating a synchronous connection when you hold it open like that. Exactly. As Jean-Marc noted, Jeff's talking more about "streaming" than "asynchronicity" (is that a word?). Well the connection itself is synchronous but that data flowing over it is async in that the server can send something to the client at any time w/o regard to the usual REQUEST/RESPONSE cycle. I guess I didn't think of it as streaming because I wasn't sending a large quantity of data over the connection, just many small chunks representing Javascript fragments to be invoked within the client. The "A" in Ajax refers, I believe, to the .async property on the XMLHttpRequest, not in how the server communicates with the client. "Ajax" processing happens in the browser background and doesn't lock up the browser. FWIW, I've been using MochiKit's Async package for writing Zope 3 apps with AJAX. MochiKit is one of life's little joys. (And I'm not being sarcastic, ask hard to believe as that is.) I looked at MochiKit and studied the Async package, but perhaps I didn't understand it. I only saw ways for the client to sneak HTTP REQUESTSs to the server behind the user's back, but nothing for the server to reach out and shove something into the client whenever the server, not the client, decided it was time. I'd rather not have the client polling the server for said data with HTTP REQUESTs. Mozilla has some support for keeping the server connection open and pushing messages to the client: http://www.xulplanet.com/tutorials/mozsdk/serverpush.php Two asides: 1) Is this better for zope3-users? 2) Benji, I've been working with MochiKit and agree that it's a real joy. Can't wait for 1.4 to get spun up. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: A Take on the Hello World Acid Test - from Mandatory Viewing
To answer the question at the end of your document: yes. Please continue on, showing the next smallest possible next step that is interesting. Hopefully this step can be done with making the viewer confront interfaces, adapters, etc. About the middle part, what's really needed to ensure newbies get a positive, confidence-building first experience? Scaffolding. Your document shows the chants needed that most newcomers wouldn't expect they should be aware of. Let's eliminate that, for that audience (if we care about that audience, which might be a different discussion.) One little Python script, maintained as part of the standard distribution, referred to ubiquitously as the right way to start, would have more impact on Zope adoption than nearly any other software activity (save, perhaps, for zope.bobo). All IMO, of course. --Paul Darryl Cousins wrote: Hi All, I enjoyed the fasterbettercheaper lecture. And it got me thinking about why I'm using Z3. Wanting to get that in words I took the hello world acid test: http://www.treefernwebservices.co.nz/hello.html Fun: 1.0 Enjoy your weekend. Sincerely, Darryl On Tue, 2006-03-07 at 11:31 -0500, Stephan Richter wrote: Hi everyone, I usually do not send messages like that, but in light of the recent discussions about vision, viewing this will give us all some perspective on what people are looking for: http://theploneblog.org/archive/2006/03/02/faster-better-cheaper I think currently Zope 3 would end up a little bit better than J2EE, but not much. I also think that the priorities the narrator sets are real ones representing a lot of people. So let's discuss this movie a little bit and see how we could do well in his evaluation. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/darryl%40darrylcousins.net.nz ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Mandatory Viewing!
Shane Hathaway wrote: Paul Everitt wrote: I still don't think scripters and developers are the same people. I won't repeat Dan's arguments here, but I think his essay is a valuable read for understanding an audience that isn't like most zope3-dev people. Once again this comes down to differing visions. Is Zope more like Excel / OOo Calc, where spreadsheet users are presented simplified but limited capabilities, or is it more like most web frameworks, which have only one audience but do their best to provide a great experience for that audience? It may not be possible to be both, due to limited resources. I realize that Dan's background makes the spreadsheet analogy apropos. Perhaps we could choose OO's new form designer, or the database wizard, as a better example. Also, regarding the last point, it's valid, but only after deciding if the audience (scripter vs. developer) even exists. For example, imagine some group cared about this and produced something for Zope which excited people like this screencaster. Imagine this effort was credible and sustained. I think there would be some portion of the zope3-dev list that might still want TTW outside of real Zope, as it wasn't a core audience/goal. This thought experiment is to find out whether Zope thinks such an audience exists and wants it, but just doesn't have the resources, or whether audiences like this guy just aren't for Zope 3. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Mandatory Viewing!
Shane Hathaway wrote: Stephan Richter wrote: My vision for the WebDev project is that you can develop WebDev packages using Zope 2 like features, but the result of the Web development can be generated into a real Python package. That might work, but the story breaks down if the developer can't switch *back* to TTW development. Have you addressed that? Does the story break down? The guy at NASA raved about ArchGenXML going from picture to pixels w/ a bunch of zeros for LOC etc. Clearly this guy didn't just fall off the turnip truck. Even if he *is* glossing over the subtleties, developer mindshare has a tinge of such gloss. Geez, Rails clearly says their scaffolding isn't meant to replace understanding, but that hasn't stopped the O'Reilly machine from doing a hark-the-heralds on the breakthrough technology. So yes, the story breaks down. But after the newcomer has confidence and might not need to go back to the TTW approach. The alternative is something perhaps too hard to start (from their perspective). --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Mandatory Viewing!
Shane Hathaway wrote: It is a beautiful story and I dearly want it to work. But the story currently has major limitations; developers reach a point where they have to make a big switch, learn numerous libraries, and rewrite a lot of their code. How can we fix that? Part of the problem is that Zope 3 makes too great a distinction between developers and scripters. Successful scripters become developers, and developers often act as scripters. I think the use cases need to see scripters and developers as the same people. The other Python web frameworks seem to be oriented this way and they've had a lot of success. Yikes, I'm about to disagree with Shane [gulp]. And on a point where ChrisM agrees with you. At this URL (from Jonah's blog post): http://www.bricklin.com/wontprogram.htm ...Dan, the co-creator of VisiCalc, argues an interesting point: [after discussing programming as imperative statements, debugging, testing, etc. The question really isn't "Why Johnny can't program" but rather "Why Johnny won't or doesn't choose to program". I still don't think scripters and developers are the same people. I won't repeat Dan's arguments here, but I think his essay is a valuable read for understanding an audience that isn't like most zope3-dev people. I won't belabor the point, as I realize that at least half the folks here aren't necessarily against the idea, they're against the mechanical problems and the "who's gonna implement it" reality. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The vision thing
Max M wrote: Geoff Davis wrote: Jeff Shell has posted some thought-provoking pieces on his blog that are relevant to Jim's recent attempt to better articulate a vision for Zope: http://griddlenoise.blogspot.com/2006/03/zope-crisis-of-faith-coming-this-march.html http://griddlenoise.blogspot.com/2006/03/crisis-of-faith-messengers-have-been.html Griddle *Noise* and thats exactly what it is... noise. "I come to bury Jeffrey, not to praise him". Jeffrey is old-school. Jeffrey is a true believer. He's been chipping in quite a bit on the threads on doing almost the entire totality of blogging on Zope 3. If we can't keep him, we're lost. I know of a few people that are dispirited by this thread. Don't be!! This is a good thread, showing that people care. They might not care the *same*, but the fact that they care is more important. Plus, I think we learned a lot in this thread. I dunno, perhaps I'm a hopeless optimist, but I think this thread will prove a pivot point for an upswing. Let's let it all hang out, baby! Let's make the case for Zope, go tell it on the mountain, etc. But Jeffrey, he's old school. He gets a pass. He's giving constructive input. Let's listen and improve. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Two visions?
Geoff Davis wrote: On Thu, 02 Mar 2006 10:38:03 -0500, Jim Fulton wrote: I think that the idea of giving Zed its own, distinct identity is great. Zope 3 is a _huge_ overhaul and it needs to be obvious to the world that it is dramatically better than crufty old Zope 2. Zope 3 then becomes the Zed application server; Zope 2 is getting Zed retrofits via Five, and the two will eventually converge into Zope 5 (or Zope 2.27 or whatever). Ooops. OK I guess I was clear as mud. :) My idea for "Z", pronounced "zed" or whatever the naming gods decide is that it was *not* an app server. It is an un-app-server. :) A collection of technologies that are useful by themselves, to support an app server and useful to build non-app-server applications, web or otherwise. No, I think I understood you. I was being sloppy in my use of language. I should have said something more like "Zope 3 then becomes an application server built around the Zed library". Good clarification. I think that Z3 is better than Z2 in a lot of ways. I also think that Z2 is more mature and complete. I really want us to combine those efforts. I think we've achieved enough and learned enough with Zope 3 that we can now bring that to bear and make Zope 2 better, refactoring the cruft away and applying the lessons we've learned with Zope 3. (Note that Zope 3 is not crust free.) I don't really care what this thing ends up being called, except that it *must* be called Zope. Yes, I agree. "Zope" is the app server. I think that is consistent with the past use of the brand. Yep. This paragraph makes me think I was clear. Yes, we need to follow Ian Bicking's advice and release our technology in bite-sized chunks. I'm hopeful that the packaging efforts underway will lead to more of that. Yes, and the use of the new name "Z" or "Zed" is a way to emphasize that the Zed library is NOT a big, monolithic app server; rather, it's something new and cool. I think this brings up an interesting paradox in the discussion. We want Zope to continue being the name of an app server. But we also want the CA to be perceived as usable outside of an app server. Outside of Zope, even. Thus, we are using the same name used to convey: "It *is* an app server!" "It's *not* an app server!" I think this might be a contradiction and might be worth discussing. People have it set in their brain that Zope is a monolithic web application server. Hard to dispel that meme. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Two visions?
Stefane Fermigier wrote: Geoff Davis wrote: I think that the idea of giving Zed its own, distinct identity is great.. I think it is stupid. We (Zope Corp + the Zope Community) have spent 8 years building the Zope brand, and you want to restart from scratch ? Hehe, poor Geoff. :) In the past, the Zope community hasn't made it a *strategic* goal to play nice with other Python projects. In the past, the Zope community hasn't made it a goal to be a sea of autonomous components. Its goal has been: top-to-bottom app server. We now have (I think!) said those goals are now in scope. Those goals are currently being met using the same name as the assembly. Trying to achieve the goals of the components, using the same word as the assembly, might not be the best way to achieve those goals. The comments I got on my pro-Zope weblog post showed that, if we *do* care about these new goals, we should consider whether the name is a barrier *for the components*. Alternatively, we could say: "The components should only be used in the Zope application server." Perhaps that's the goal. I think Geoff's core point could be met by keeping the word "Zope" for the app server. I think Geoff's deeper point was to rethink the word used for the CA, which actually doesn't want to be thought of us an app server. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-Users] Visionaire! (All your problems, solved)
Jeff Shell wrote: Yes. There's a dominant Zope name out there. It's not the Component Architecture nor is it built on it. It's starting to use it, but it's not based on it. However, since the project that Zope 3 [AS] came out of is still identified in the Wiki as the 'Component Architecture' project, maybe the '3' can be dropped for that one. But not for application server: That dominant Zope, aka Zope 2, is also an application server. So there really needs to be a separate definition. This was discussed here a couple of months ago when people were enamored with the concept of totally different names or code names or release names, which I was against. Zope 3 is Zope. But Zope 3 is Not Zope. Zope 3 has *some* degree of buzz around it, more than something with a new name. I still believe that the '3' has meaning, at least for now. Maybe it can disappear over time. [snip] Caveats up front: 1) I know I don't have much useful to say, but I will anyway. :^) 2) I wholeheartedly endorse the discussion Jim has prompted. He is making some observations that are getting lost in the discussion about his proposed solutions, IMO. 3) I think the observations you just made are similar to his observations. I think Jim's point can be summarized in a famous quote from the ancient philosopher Ric Flair: "If you wanna be the man, you gotta beat that man." If you want call yourself Zope, what expectations do you need to meet for what audience? Alan and Alex brought up a nice discussion once about Plone having a middle class. Zope used to have a middle class, but Zope 3 has left that group in a "to be determined later" status. Which is odd, as creation of a middle class was what really differentiated Zope. Now we have to compete on very similar terms to other projects (and we're getting crushed on the mindshare.) So if you're going to call yourself Zope, you probably have to say "we love our middle class". If you don't, the odds are stacked against you, as you have to appeal to people that have a negative connotation of "Zope". For the most part, Zope 3's primary uptake is the CA. I would be surprised if more than 10 installs in the world have end-users using Rotterdam. I would also be surprised if there are more than 20 people worldwide in Zope 3's "middle class". Instead, Zope 3 components get used by Zope 3 component developers to build completely new finished applications atop the CA. Or the components get used in Zope 2 or non-Zope systems. On the latter point, I think Zope 3's future is in granularity. Others have said this too. Zope's battle-hardened bite-sized chunks do things other projects simply don't contemplate. But let's face it...as long as those chunks wear the name "Zope", half of the other projects will never consider it. "It's a competitor", "I tried Zope and hated it", "I don't like Python databases", "Don't make me march under your flag", and other feelings that, while things have changed in reality, are true in perception. On to a concrete proposal, which I realize is just another log on the fire: 1) Audience==Middle class: Keep the name Zope to apply to the application server and the middle class. Basically, Zope is the assembly. 2) Audience==Python: Pick a new name for the top-level package of components. For example: "zed3" for the naming. E.g. zed3.pagetemplates. (Examples: SchoolTool, Tiks, Oxfam America via Enfold, etc.) Don't heavily brand zed3. Stated differently: brand the sea of components different than the assembly into an app server. Market the first at the people that actually liked Zope. Market the second at the people that didn't like Zope. Over time, make the first built out of the second. If you're in the "change Zope 3 and I'll leave" camp, you're probably most interested in the components. You're probably not interested in deploying end-user application server deployments. You're probably not interested in the middle class. None of Zope 2 would ever make it into the zed3.* package space. So nothing to fear there. This tries to solve the branding problem mentioned of "introducing one more name". For people interested in the app server, for the middle class and the business decision maker, there is no change: it's Zope 2 blending with/into Zope 3. For people interested in the components...let's face it, the word "Zope" would have been a dead-letter anyway. For *that* audience only, there is a new word involved. People who detested Zope (check comments my weblog post for evidence thereof, nice to know Satan commissioned Zope) are *really* unlikely to return to the word "Zope". --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Persistent Schemas?
Lennart Regebro wrote: On 3/1/06, Chris Withers <[EMAIL PROTECTED]> wrote: Does this help with implementing persistent schemas at all? Maybe, although I feel that the interface-based schemas was a mistake anyway. It would probably be better to focus energy on making XForms based schemas, both persistent and not. Just my 0.02€ I'll pitch in my two centimes as well. Not only that, but I'll actually work on the implementation. :^) I'm already doing XForms-style TTW dev in a pet project. I'm personally interested in TTW approaches that look at the problem from a different perspective. I realize that (a) not everybody will have that perspective and (b) trying to prod others to do it isn't fair, that I should do it myself. In a nutshell, my perspective is that the TTW environment should use TTW technologies. It shouldn't try to make some semi-restricted, safe subset of the on-disk technologies work correctly "TTW". I also endorse the idea others have made of not making this part of the core. Perhaps not even use the name Zope for the TTW package, similar to how Rotterdam originally intended to have its own mini-brand. In fact, perhaps the effort could be done without really being tied to Zope at all. TTW dev that provided REST-style introspection and updating. Glue code (I'm envisioning lxml's namespace extensions) that make the object model and TTW model seamless. Anyway, that's all just my silly little perspective. :^) Until I actually show anything, it's moot. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Zope 3 Marketing Competition? (was Re: [Zope3-dev] Re: Selecting a code name)
Stephan Richter wrote: On Monday 06 February 2006 20:49, Gary Poster wrote: How about we have a marketing competition? :-) +1 from me plus everything else you said below. Yep, it's a good idea. --Paul ___ 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: Publication Post-Processing
Jim Fulton wrote: At: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PublicationPostProcessing I've put doesn some thoughs for discussion on making the publication APIs more explicit and for supporting post processing tasks like adding standard look and feel or adding missing page components. I've read through this a couple of times now. First, thanks a bunch, Jim, for putting so much thought into it. Couple of thoughts: 1) I don't know if it is or isn't in-scope to discuss page composition outside of Zope server. Consider the headings under "Need for page-composition support", "Pipelines", "Transitive Adaptation", and the subset described under "Subscription". It might be possible to also do these inside a WSGI Twisted in Zope 3.2, for example. It might also be possible to do these in mod_python. They all depend on whether "Publication Post-Processing" should be able to access content *beyond* what enters the publication process. 2) Regarding ordering of events for subscription, it reminds me of (my apologies for this) XSLT. You can have multiple temlates matching on variations of the same "event", so to speak: The spec and decisions made by implementors govern which matches. If I understand it correctly, they seem to have reached the opposite conclusion as you. More specific matches first, more general doesn't get called. I like the merits of your thinking, though: "It might be argued that invoking more general subscribers first is, in fact, a reasonable, as it allows specific subscribers to build on work done by more general subscribers." 3) I'd be interested to hear how testing could be woven into the adapation process you describe. Meaning, ways to make statements about the structure of the things coming in and going out. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ANN: Zope activities at EuroPython 2005, Jun 27-29, Sweden
Tim Terlegård wrote: On Sat, 21 May 2005, Paul Everitt wrote: Z3 ECM Sprint - There are several sprints getting organized at EuroPython. The Z3 ECM team is planning a pretty serious effort to kickstart its activities. The Z3 ECM sprint starts at noon on Thursday, June 23 and goes through Sunday, June 26. Does anything happen June 30-31? That's when I plan to be there :) I don't know of anything that will be scheduled, except my flight home. :^) These sprints, will they be about discussing and about design or more about producing code? Likely a bit of everything. A few people (Florent, Julien, Jean-Marc, and me) have proposed some targeted topics. We also need to have some planning for this Z3 ECM effort, to use face-to-face time for agenda setting and core decisions. Do zope 3 beginners have anything to learn from those workshops or would they do better staying home reading a Zope 3 book? I'll defer to Tres on this. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] ANN: Zope activities at EuroPython 2005, Jun 27-29, Sweden
Hi all. We're planning some Zope activities at the EuroPython conference next month in Sweden: http://www.europython.org/ In short, we have: o The Zope track, with over twenty presentations covering CPS, Silva, Plone, Zope 3, and other Zope topics. o A keynote by Tres Seaver, creator of the CMF. o A closing panel on CMS like last year. o A dedicated Zope Lightning Talks session. o A Z3 ECM sprint just beforehand with hands-on workshops for specific topics. This year has more Zope packed into it than any previous EuroPython conference. Particularly with the recent activities in Z3 ECM, there's lots of don't-miss stuff this year. Please register soon and get involved! More details for each of the items on the agenda. Zope Track -- The Zope Track this year has a spotlight on each of the CMS projects for Zope. Particular focus is given to the work being done with Zope 3. The talk listing is now up-to-date with the accepted talks: http://www.python-in-business.org/ep2005/alisttrack.chtml?track=694 Zope Keynote - In keeping with the emphasis on content management for Zope, the keynote this year will be given by Tres Seaver. Tres is the creator of the CMF, upon which CPS and Plone are based. He will be talking about the impact of Zope 3 and the ongoing work to make a shared CMS layer in the Z3 ECM project: http://www.palladion.com/home/tseaver/obzervationz/europython_2005_invite Z3 ECM Panel - This part is a bit of vapor-talk, as the panelists don't even know about this yet. Last year the track ended with a panel discussion in which the leaders of major CMS products for Zope discussed the impact of Zope 3. In particular, could the projects collaborate in a way similar to the CMF? The audience participated quite a bit and Jim Fulton led a very useful discussion. This panel then led to the Z3 Castle Sprint in 2004 and the Paris Sprint several months ago. We now have a project setup for the Z3 ECM effort: http://www.z3lab.org/ This year's panel will be a place for the Z3 ECM team to inform the audience about the shape of the project and solicit feedback about goals and objectives. Tres will be the moderator this year. Zope Lightening Talks -- Following the Faassen Format for lightening talks, this session is meant to be fast, fun, and slightly raucous. Lightening talks allow topics to spring up during the conference and get ten minutes of fame. Z3 ECM Sprint - There are several sprints getting organized at EuroPython. The Z3 ECM team is planning a pretty serious effort to kickstart its activities. The Z3 ECM sprint starts at noon on Thursday, June 23 and goes through Sunday, June 26. Tres Seaver will be the overall sprint leader. Topics include: o Florent Guillaume ([EMAIL PROTECTED]) is leading a session for a Zemantic-based repository, with relations covering versioning, multilingual content, and more. o Julien Anguenot ([EMAIL PROTECTED]) will lead a team working on the the ECM workflow architecture and continue the existing prototype. Discussion about the WfMC standard and the 3 architecture layers (xpdcore/wfmc/ecmworkflow) plus the existing work on the Zope 3 trunk is planned. o Paul Everitt ([EMAIL PROTECTED]) will lead a hands-on workshop for "Model-Driven Ajax". This will be a start-to-finish walkthrough of creating dynamic browser applications using XML, JS, and XSLT. Focus will be on a productive workflow for UI development. This workshop starts on Saturday. If you are interested in one of these topics, please contact the the people individually. If you are interested in leading a session, email Paul. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3 / ECM] : Project launched !
Maik Röder wrote: Hi, - to unify the whole Zope/CMS-involved community to drastically reduce waste of resources (doing twice or more equivalent components / features). How do you plan to keep the project apart from the interests of Nuxeo? Although Julien's intro said Paris and on behalf of Nuxeo, the Z3 ECM project is a joint collaboration between CPS, Silva, Plone, and any other CMS or individual developer that wants to work together for the move to Zope 3. We've all made a very strong effort to collaborate and not promote our individual projects ahead of the common goal. The Zope track at EuroPython will promote this idea of working together, as will the planned Z3 ECM sprint the weekend before the conference. So far things have gone well for this as a group effort: the panel discussion closing last year's conference, Philipp and Martijn's Z3 Base from last year, a sprint that Jim led and all the projects attended in Vienna, a sprint in Paris that had people from all projects participate. It's now time to start pitching in some resources and getting some things done. Nuxeo is in the lead on this part. I'm planning to do a two-day workshop at sprint. We are actively hoping to line up the shared goals with individual goals. --Paul ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
