[Zope-CMF] Plone/Metadata/FUD

[hazmat]

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