[Zope-CMF] Plone/Metadata/FUD

[Erik Lange]

Hi,

Sorry 'bout the FUD :-(

Please notice that I said I would like an activity based workflow _like_ 
OpenFlow... I didn't say that it should be OpenFlow... I also said that it 
should work as a seperate product... so I don't think that I was advocating 
for depencies from CMFCore or Default to OpenFlow...

I do believe that Alan in every single mail he has sent us, has advocated 
strongly for us to join the Plone-team - how can I in a polite way say that 
Plone isn't a product we are going to invest any development in, because we 
don't find it usefull  to us ?

Are we "bad people" because we don't like Plone ?

Regards,
Erik

At 08:48 AM 10/3/02, hazmat wrote:
>On Wednesday 02 October 2002 05:15 am, Erik Lange wrote:
> > > At 01:56 PM 10/2/02, hazmat wrote:
> > > >On Tuesday 01 October 2002 11:54 pm, Erik Lange wrote:
> > > > > At 03:09 AM 10/2/02, hazmat wrote:
>
><snip>
>
> > > >
> > > > MMM Skins fullfills our need for a nicer look on the CMF... it looks
> > > > just like Plone, but doesn't do anything else... we hope ;-)
> > >
> > >very cool.
> >
> > It's my believe that this is actually what people want, when they go for
> > Plone - a nicer look than default CMF - that was also why we in the first
> > place even bothered to look at Plone... It's fine that Plone wants to be
> > more than just that, but since that's the main reason people choose to use
> > Plone (IMHO), it should be made clear that Plone is _not_ a skin for CMF!
> >
> > And I believe it would be polite of the Plone-dudes, to provide such a skin
> > themself... but until they do we're happy to assist ;-)
> >
> > ( Our "codename" for MMM Skins is "Plone rip-off" ;-) )
>
>ok, so your forking plone look and feel without attribution. cute.
>
>onto workflow aka the dead horse
>
> > > > >the other thing i'm hearing is about compatiblity with workflow,
> > > > > which is a big copout imo. because i've used plone with alternative
> > > > > workflows, and it works fine. if other products can't work well with
> > > > > a different workflow because they are *hardcoded* to a particular
> > > > > workflow, i consider that a product bug. simple as that.
> > > >
> > > > Well.. you have misunderstod what I was saying.
> > >
> > >maybe, i'm still not sure what your saying wrt to workflow.
> >
> > I don't want a workflow that depends on other products, as I believe Plone
> > workflow will depend on Plone, in the CMFCore or in the default
> > implementations (i.e. CMFDefault).
>
><snip>
>
> >
> > And if Plone workflow works without Plone and gives me something that the
> > other dosn't provide, it would make sense to distribute Plone workflow with
> > CMFDefault.
> >
> > But I don't belive Plone workflow does that ?
>
>repeating myself.
>
>i don't think anyone ever suggested the plone workflow become the default.
>
>and if it were, it sure as hell wouldn't be dependent on plone.
>
>i know the subject has FUD in it, but will you please stop spreading it.
>
>hmm.. neither polite nor humor seem to be getting through
>
>/me takes of his gloves and gets a baby bottle
>
> >
> > What I would really like to see in CMFDefault is an activity based
> > workflow, like OpenFlow, to suplement the different actionsbased workflows
> > it comes with today.
>
>it ain't gonna happen. first there is a license issue, openflow as it stands
>today is gpl, nough said. second, you seem to have a basic misunderstanding
>of how the cmf works or component models in general. dcworkflow isn't
>distributed with cmf either, the default workflow is very basic. But their is
>this nifty concept called interfaces, and another one called services aka
>tools.  services like workflow have an interface that allows for pluggable
>implementation, so it doesn't really matter what comes with cmfdefault cause
>you can plugin your own workflow engine, like openflow or dcworkflow. third
>the openflow model is way more complex than what people need, some people
>are happy with cmfdefault workflow.
>
>its already been by others and myself, but it i seem to have to repeat 
>things,
>CMFDefault isn't meant to represent what can be done with cmf, its just a
>convienent starting point for customization.
>
> >
> > > > I recognize that it's usefull for many users - but that shouldn't have
> > > > _any_ impact on those for whom it isn't... or should everybody just
> > > > shut up and see the light and use Plone all over to make it easier for
> > > > you as a developer ? ;-)
> > >
> > >smily faces don't make rude comments any better.
> >
> > Uhm... that wasn't meant to be rude :-(
>
>nevertheless it was, and after reading your latest salvo of emails in a
>private thread that was attempting to resolve this its apparent that you have
>been consistently accusatory, argumentive, and occasionally flat out rude.  i
>don't really understand what your trying todo by this conversation, because
>its certainly not trying to reach any shared understanding or be
>constructive.
>
> > It was more like a summery of how I've interpretated Alan's mission for
> > Plone... now that might be a bit rude, if I have misunderstood Alan on this
> > point... If I haven't misunderstood Alan on this, I believe it's Alan who
> > is rude to the community...
>
>so apparently all this FUD, is based on some character assesment that you 
>made
>of alan, a person you've never met. a person. a person who spends his time
>working on a making an open source product, and helping people on the
>zope/cmf mailing lists, and on irc. i guess its more character assasination
>then assesment.
>
>charming.
>
> > >again, i fail to see the issue, *no* one is talking about making plone
> > >workflow default for cmf, and i seriously doubt most people with workflow
> > >needs are content with the default workflow out of the box, ie without
> > >customization, so i'm confused how changing the default would matter to
> > > you.
> >
> > If it depends on specific products and can't be used stand alone, it
> > bothers we...
> >
> > > > We are looking for activity based workflow, and not action based -
> > > > that's why I belive Plone-workflow won't be the one for us... sorry
> > > > about that, don't take it personal.
> > >
> > >well your likely to benefit from some work sponsored by a company using
> > > plone for the cmf, ie openflow integration, that is assuming of course,
> > > your not writing your own.
> >
> > We're quite bussy here, so at the moment we just use what is there - as
> > soon as we get a little air, we would be happy to contribute to OpenFlow...
> > I don't see why we should do OpenFlow development in a Plone enviroment...
> > do you ?
>
>see above exposition on interfaces, and pluggable implementations. obviously
>if  openflow is going to be used in the cmf, its going to meet the cmfcore
>workflow tool interfaces. you'll note i didn't say anything above about
>developing in a plone environment, just to repeat myself again in relation to
>openflow migration, it is 'sponsored by a company using plone for the cmf'.
>if you want to plugin additional ui so that it works better for you, feel
>free to do it in your, "Plone rip-off" skin.
>
><snip>
>
> > > > >does anyone consider CMFDefault a fork of the CMF?, its a
> > > > > customization that adds useability and functionality that mirrors
> > > > > usecases that for zope.org, but its hardly an end user product. i
> > > > > don't see developers running to use CMFCore bare, because it doesn't
> > > > > provide alot of functionality and useability from a developer pov. in
> > > > > a similiar vein i do see users flocking to use plone, because for
> > > > > them it provides functionality and useability out of the box. these
> > > > > aren't forks they are progressively layerd systems that build
> > > > > functionality that users and developers can avail themselves of. ie
> > > > > Zope->CMFCore->CMFDefault->Plone.
> > > >
> > > > I agree on the above. But what about this:
> > > >
> > > > Zope->CMFCore->CMFDefault->Plone - rolling back - Plone->CMFCore , next
> > > > gen = Zope->Plone... where did CMFCore go ?
> > >
> > >the core semantics of the architecture got rolled into zope3. ie
> > > centralized services, views components detached from object models, etc.
> > > which would make these semantics available to any zope product, which is
> > > a *great* thing, imo.
> > >
> > >otoh, zope3 is a whole new ball game, and predicting how its going to be
> > > is a chancy thing, unless of course people start helping out, and making
> > > it the platform they want to use.
> >
> > Now you're talking !
> >
> > Let's get the development resources of the CMF community focused on this,
> > rather than on an external 'thingy' :-)
>
>i'd love to have more people working on zope3, but most of us (myself
>included) have to do paid work with whats available now.
>
> >
> > > > Why  can't Plone contribute with seperate products from the
> > > > Plone-package, instead of going for replacement of CMF with the full
> > > > package ?
> > >
> > >plone isn't replacing the cmf, its building ontop of it.
> >
> > And adds it's own framework wich to some extend makes it incompatible with
> > the default framework.... IMHO.
>
>see above re interfaces and pluggble implementations.
>
> >
> > >its installation is gestalt, because plone's primary market/audience is
> > > not developers, its end users who want and get a point and clicky
> > > install.
> >
> > So let them have it :-)
> >
> > Why do I need it ?
>
>hey, i get to repeat myself again... i'm noticing a pattern. no one said you
>did. no one's forcing you to use plone. plone is not forking the cmf. plone
>is not replacing the cmf. sigh..
>
> > > > It's this mental twist, that "if we just accepted Plone and embraced
> > > > it, there would be no problems", that I'm against - not Plone as a
> > > > product in itself, but the impact it seems to be having on CMF
> > > > development.
> > >
> > >you mean like bringing lots of new users around?
> >
> > No - I mean focusing the development resources of all the new users on
> > Plone development.
>
>hey, i get to repeat myself again. .. i'm noticing a pattern. plone is
>targeted towards end users. people that want a *product*, ie little assembly.
>CMFDefault is geared towards developers who want to customize a particular
>type of cmf site. or perhaps new developers want a feature that plone
>supports like il8n, or they rather spend their time doing domain logic than
>ui. iotw. maybe they use plone, because they want to use plone. what a
>radical concept.
>
> > >i really don't buy that plone is so different from the cmf functionally or
> > >that its some big hinderance to generic core development, at least i
> > > haven't seen any evidence of such. i see it spurring *generic*
> > > development in some respects.
> >
> > Chris gave a fine example on this with how CMF Calendar was "ported back"to
> > CMFDefault...
>
>and now plone uses the one from cmf default...
>
> >
> > > > It's like Plone or nothing at all... and allthough Plone has a broad
> > > > appeal, it won't be a product for _everyone_, unless you're thinking
> > > > the Microsoft way ... if you belive that Plone should be the future
> > > > base of CMF (as I feel Alan believes), I will feel we have been
> > > > "forked". It's way to limiting in it's complexity for a base-product
> > > > like CMF. Some of the component might be nice - but let me choose
> > > > between the components I want to use on top of our common base in the
> > > > future.
> > >
> > >i'm all for choice. i don't see the consipiracy theory.  how has your
> > > choice as developer for using the cmfcore/default been negatively
> > > impacted by plone?
> >
> > 90% of all mails that should be focused on developing CMF / Zope3, are
> > "snapped" from this list with a "we're working on that at Plone, come join
> > us!"
>
>WOHOO!, a credible statement for advancement of discussion. well semi 
>credible
>as i've already stated zope3 is bit on the horizon for most people. the fact
>is getting new functionality that isn't entirely clean and polished may not
>be what people want in the cmf. ie. plone has a portal_validation and state
>navigation tool. i don't use it, and i don't want it in the cmfcore. perhaps
>with your vast experience in contributing to the cmf, you can help decide
>things that are good candidates to be ported back (plone free of course) back
>to the cmf.
>
>otoh maybe people want these functionalities even if they aren't generic
>enough to go back into the cmf. if thats your beef, well take it up with the
>newbies, write a document extolling the virtues of doing your own ui layer,
>and il8n'n all of those custom templates, etc.
>
> > Instead they should be saying "we at Plone are also pissed on that - lets
> > do something about it, and fix that shitty product to work with both Plone
> > and CMFDefault"... rughly speaking ;-)
> >
> > The above approach removes the focus from CMF development, where it
> > shouldn't - IMHO.
>
>sorta like this discussion.
>
> > >i haven't heard anyone advocating that plone replace the cmf, not to
> > > mention even in the *worst case* if every plone user and developer were
> > > for it (which their not, imo), there are several cmf consulting companies
> > > who don't use plone (zc included), so why do you think that the plone is
> > > going to replace the cmf?
> >
> > Because Alan advocates for Plone's extra functionalities should be ported
> > back into CMFCore/Default - I don't see why and fear it will end with
> > CMFCore depending on Plone...
>
>to me this is just a totally irrational statement, find a single person with
>cvs commit, that thinks that cmfcore is going to depend on plone, if not take
>your FUD home with you.
>
> > > > If You're missing something in the base - make it there and not in
> > > > Plone.. specialized workflows are not a part of the common base - IMHO.
> > >
> > >um.. thats a contradiction, but i think i understood what you meant...
> >
> > If you're messing with core-components, these must never have any
> > dependencies to other products - then it won't be a base component anymore
>
>like making cmfdefault depend on openflow. right.
>
>" ogre are like onions, they have layers! "
>
>and i think i've peeled enough off this conversation to realize that its
>basically a circular argument composed of fear, ignorance, and contradictions
>all the way down, and i'm done with it. back to some cmf development.
>
>-haz
>
>
>
>_______________________________________________
>Zope-CMF maillist  -  Zope-CMF@zope.org
>http://lists.zope.org/mailman/listinfo/zope-cmf
>
>See http://collector.zope.org/CMF for bug reports and feature requests