Joomla 1.6 will be a killer. Wow, The ACL is the best of its kinds and
it looks very elegant and beautiful. (It is by far the best things
ever happened to Joomla!) and the new templating system and the
unlimited category depth system.
Occasionally I have been reading this group's posts and I have seen
some of you working on a Multi language solutions. I was wondering why
would you want to re-invent the wheel when we have Nooku around the
corner.
It is a killer translation tool and a killer framework too which would
reduce the amount of code needed to develop for Joomla!
How about the Google Summer of Code projects for 2008 and 2009?
Are they going to be incorporated into Joomla or not. if NOT, then
why care having Google Summer of Code projects at all?
Thank you very much for all your hard and outstanding work.
All the best
SaMMY
Hannes
I am of course a Nooku user, and may so be regarded as being biased,
but I have written components both for "vanilla" Joomla and Joomla
+Nooku, and I can tell you there is a world of difference. Even with
the early releases of Nooku.
Also, regarding the "Joomla is already a framework" (and does not need
another one) statement, Nooku isn't a framework like Zend or Symfony.
It is written by, among others, Johan Janssens, who also wrote large
parts of Joomla 1.5, so stuff like the MVC pattern is identical, and
it is written to be compatible with Joomla to begin with. An ideal
scenario for Joomla, in my humble opinion, would be to use Nooku FW
for Joomla 2.0 or something. Please note: I did not write imho because
I feel strongly about this. Joomla is behind in more areas than
usability. With Nooku there is a nice opportunity to make up for lost
progress.
Yes, Joomla is indeed a framework, but it has fallen behind in
development. Badly.
I have no opinion on the conflict that led to Johan leaving the core
team and started work on Nooku, but in hindsight there is no dubt
where the real development progress has been happening. It is sad, and
from the outside it seems very egocentric, to let personal differences
between very few individuals halter opportunities of progress that
would be enormously beneficial to the Joomla project and all of it's
users.
- Torkil
why?
- It takes a lot less code to write an extension
- the code runs faster
- The code is much more portable and flexible
- Very easy to call the models and views of other components reducing
repeated code and bugs for plugins and integrations between components
- Very easy for modules to call the models and views from components,
reducing repeated code and bugs
- Because models and views can be reused, developers only need to
update in one place to fix their components, modules and plugins.
Reducing bugged or forgotten add on upgrades
- Models have much more secure default, automatic data validation
(based on db column types) reducing a major, major, major Joomla
problem - security holes in 3pd extensions (it can of course be
overwritten with custom if needed)
All in all it is at least 20 times better to work with than the
current framework, with the major drawback being simply that it is a
bit unstable right now, but that wil change with the stable for 0.7
due soon.
I would like to see a good list of advantages to keeping the current
framework, because I can think of none myself. Especially given that
every major release breaks backwards compatibility anyway, there
should be no issues there.
Koowa based extensions will be more stable, more reliable, more
secure, have more features, be more interoperable, less code, less
redundency and less bugs than those done with the current framework.
Especially given that it was written by the same guy responsible for
most of the current framework, it almost can't not be better.
Please, please, please bring the Joomla framework up to date with
modern coding practices, or provide us with some better reasons why
not to than just "we don't need another framework" as that is not a
very confidence inspiring argument.
Sam Moffatt
http://pasamio.id.au
> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>
The code is there, and all the good reasons to use the code is there
too.
On Apr 9, 2:08 pm, Sam Moffatt <pasa...@gmail.com> wrote:
> The people who write the Koowa Framework (the framework behind Nooku)
> are welcome to sign the JCA and contribute their work to a branch and
> have it included in the core. It isn't our decision to make until it
> is sitting in a branch.
>
> Sam Moffatthttp://pasamio.id.au
Sam Moffatt
http://pasamio.id.au
Elin
On Apr 9, 9:57 am, dukeofgaming <dukeofgam...@gmail.com> wrote:
> Though I have not used the framework, I've seen it and seen what its capable
> of and how. Perhaps the technical implications are obvious, but I think if
> this is to be take seriously I think the discussion should head towards
> project implications (on both sides).
>
> I think the GPL license progresses as far as half the way, but a case should
> be prepared IMO.
>
> On Fri, Apr 9, 2010 at 7:53 AM, Rafael Diaz-Tushman <
>
>
>
> rdiaztush...@dioscouri.com> wrote:
> > @Torkil: agreed.
>
> > I see several thousand lines of code in the Joomla 1.6 trunk from devs
> > like Ryan Parman and Geoffrey Sneddon (simplepie), Edd Dumbill
> > (xmlrpc), Andy Prevost and Brent R. Matzelle (phpmailer). Did they have to
> > sign the JCA?
>
> > --
> > Rafael Diaz-Tushman, President & CEO
> > Dioscouri Design: Form and Function
> >www.dioscouri.com
> >www.twitter.com/dioscouri
>
> >> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
> >> .
> >> > > For more options, visit this group athttp://
> >> groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Joomla! CMS Development" group.
> >> To post to this group, send an email to joomla-...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Joomla! CMS Development" group.
> > To post to this group, send an email to joomla-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
I agree with Torkil and Danayel that there is real value in working
with Johan, and Mathias, and the other Nooku developers. Clearly,
Nooku is superior to the Joomla! core framework in specific areas and
we would be stupid not integrate those advantages into the core for
everyone.
Andy Miller's Gantry is another example of a framework, this one for
Templates, that I think is certainly worthy of consideration in a 2.0
Joomla! solution. http://www.gantry-framework.org/
K2, as well, is obviously meeting a need and getting Fotis involved in
2.0 is also very important.
Yesterday, Hannes posted comments on the "1.6 Road to Beta" thread
that I believe were right on the money. Joomla! is way behind in terms
of core architecture. It's true, there is simply no denying it.
However, we are not behind any other project in the world when you
consider the collective intelligence in this developer community and
the third party solutions already available.
For 2.0, I would love to see developers share their visions of where
things should go. It would be nice to have a video, a set of
documentation and code that could implement this vision and allow
everyone to work with the code. In addition (and most importantly), it
would be good to hear what each developer is willing to do to bring
their ideas to life, what role they would like in helping develop 2.0,
and even what long-term commitment they are willing to assume in
keeping that aspect of the core moving forward.
I understand that we don't want to bloat core with features. One goal
might be to reduce the size of core *considerably* and embrace core
Extensions that are helpful to site builders. There is simply no
reason for 10-15 CCK's, each lacking ability to integrate with all
Components, etc., etc. We need one of those and an API developers can
use. We need one set of Spam handlers and an API for everyone. There
are a lot of application elements that would benefit from better
integration and it's time for us to work on that layer as a
collaborative community, as well.
Can you imagine a team of 20 developers from the community - each
taking a piece - and pulling together innovative solutions available
now into an integrated super Joomla!? The project could focus on the
project management role and quality control aspects, ensuring things
stay on schedule and meet standards.
This could easily happen. We would not only catch up with the other
projects, but we would have a sustainable organization, driven by
community, and healthier expectations about the role of community to
contribute towards shared solutions.
Glad this topic was raised. I say "of course!" to Nooku, and throw in
Gantry, K2, and whatever else all of us are willing to share - commit
to develop - and sustain.
On Apr 9, 7:22 am, Ruud van Zuidam <r...@bluecove.nl> wrote:
> Although I'm ik big fan of Nooku framework, I don't think
> this discussion helps or should be held here,
>
> it looks like the strict guideline's for development and strong leadership
> with a clear vision, the "*where do we go from here and witch road do we
> take*",
> are left for "* I'f you don't mess my pet project I won't mess with your's*"
> .
>
> and we can't change that, in fact we should not even try that, the problem
> will solve it self.
>
> I'f you see what is happening om 1.5 development now a days, template
> designers are building frameworks and become developers and coders,
> extension developers are building frameworks, cck's
> and even Content Application Builders, it's like Europe after the fall of
> Rome, everybody is building his own kingdom, times will be interesting to
> see who will be Carles V.
>
> I wonder if this is what Wilco Jansen meant when he spoke over developing on
> top of the framework and seeing the framework as an independent part
> Joomla!, on withs the core development should focus !!!, leaving the
> development of extension's to the community developers and there creativity
> and needs
>
> *"May you live in interesting times"-old Chinese curse** *
>
> Ruud van Zuidam
> M +31 (0) 614356963
> T +31 (0) 523-685435
> F +31 (0) 523-684186
> KvK Zwolle 05069464
> BTW NL-8126.45.716.B01
> i...@bluecove.nlwww.bluecove.nl
>
> Disclaimer
>
> De informatie verzonden in dit emailbericht is vertrouwelijk en is
> uitsluitend bestemd voor de geadresseerde. Openbaarmaking,
> vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan
> derden is, behoudens voorafgaande schriftelijke toestemming van Bluecove
> niet toegestaan.
>
> The information sent in this email message is confidential and it has been
> exclusively intended for the addressee. Publication, multiplying,
> distribution and/or supply of this information to third parties have not
> been permitted, subject to preceding written authorisation of Bluecove.
>
> > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsu...@googlegroups.com>
The more that is added to core, the bigger and harder the job it
becomes to maintain it not only in terms of forward movement and
progression, but in terms of security, compatibility, coding
standards, testing....etc.
Nothing is stopping anyone from adding anything they want to Joomla!
themselves. If someone want to use "framework-foo" with Joomla, they
are quite able to do so. If someone doesn't want to use "framework-
foo" but instead wants to use "extension-bar" they are fully able to
do that too. If a developer wants something included in the core they
just need to put it in a branch. Nothing is stopping anyone from
doing that.
Less in core, means more options for end users IMHO, I also don't
think this is a game of catch-up nor is it a race or a competition.
There is nothing stopping 20 developers from the community right now
from pulling together and contributing right now. Nothing stopping
100 developers from doing so. Just one look at the JED and the JRD
you see that there are hundreds of devs contributing to the community
in a myriad of ways.
Jenny
On Apr 9, 9:26 am, Amy Stephen <amystep...@gmail.com> wrote:
> Good to see Ruud point out all the frameworks emerging. When Template
> Developers start to build applications on top of the application (kind
> of like an inside out framework), something is going on. One obvious
> possibility is that the application is no longer meeting the standard
> for current applications. A second possibility is that developers
> (including the Template folks) are positioning cross-CMS. To a certain
> extent, both are likely the cause.
>
> I agree with Torkil and Danayel that there is real value in working
> with Johan, and Mathias, and the other Nooku developers. Clearly,
> Nooku is superior to the Joomla! core framework in specific areas and
> we would be stupid not integrate those advantages into the core for
> everyone.
>
> Andy Miller's Gantry is another example of a framework, this one for
> Templates, that I think is certainly worthy of consideration in a 2.0
> Joomla! solution.http://www.gantry-framework.org/
The only public versions of the JCA are drafts and have DRAFT stamped
across them. Whats the text of the ones that are being used?
Transparency :-)
Kindest regards
Phil.
On 09/04/2010 15:53, Ian MacLennan wrote:
> All contributions from JXtended have been submitted by organizations and
> individuals who have signed the JCA.
>
> Ian
>
>
> 2010/4/9 klas berlič <klas....@gmail.com <mailto:klas....@gmail.com>>
>
> As Nooku is GPL it can be used by anyone to incorporate it in GPL
> project as license allows it.
>
> But without JCA copyrights must be retained and that shouldn't be a
> problem as example case has been already done with larger code
> contribution by JExtended.
>
> Form administrator/com_comments/manifest.xml
> <copyright>Copyright (C) 2008 - 2009 JXtended, LLC. All rights
> reserved.</copyright>
>
>
> 2010/4/9 elin <elin....@gmail.com <mailto:elin....@gmail.com>>
>
> No because they licensed their code already.
>
> Elin
>
> On Apr 9, 9:57 am, dukeofgaming <dukeofgam...@gmail.com
> <mailto:dukeofgam...@gmail.com>> wrote:
> > Though I have not used the framework, I've seen it and seen
> what its capable
> > of and how. Perhaps the technical implications are obvious,
> but I think if
> > this is to be take seriously I think the discussion should
> head towards
> > project implications (on both sides).
> >
> > I think the GPL license progresses as far as half the way, but
> a case should
> > be prepared IMO.
> >
> > On Fri, Apr 9, 2010 at 7:53 AM, Rafael Diaz-Tushman <
> >
> >
> >
> > rdiaztush...@dioscouri.com
> <mailto:rdiaztush...@dioscouri.com>> wrote:
> > > @Torkil: agreed.
> >
> > > I see several thousand lines of code in the Joomla 1.6 trunk
> from devs
> > > like Ryan Parman and Geoffrey Sneddon (simplepie), Edd Dumbill
> > > (xmlrpc), Andy Prevost and Brent R. Matzelle (phpmailer).
> Did they have to
> > > sign the JCA?
> >
> > > --
> > > Rafael Diaz-Tushman, President & CEO
> > > Dioscouri Design: Form and Function
> > >www.dioscouri.com <http://www.dioscouri.com>
> > >www.twitter.com/dioscouri <http://www.twitter.com/dioscouri>
> >
> > > On Fri, Apr 9, 2010 at 9:24 AM, Torkil
> <torkil.john...@gmail.com <mailto:torkil.john...@gmail.com>> wrote:
> >
> > >> The people behind the Nooku Framework doesn't have to sign
> or upload
> > >> anything, Sam. They have already contributed the code by
> making Nooku
> > >> Framework GPL, and on top of that Joomla compatible. You
> can make the
> > >> decision to use Nooku today if you want to, and then
> actually start
> > >> using it literally minutes later.
> >
> > >> The code is there, and all the good reasons to use the code
> is there
> > >> too.
> >
> > >> On Apr 9, 2:08 pm, Sam Moffatt <pasa...@gmail.com
> <mailto:pasa...@gmail.com>> wrote:
> > >> > The people who write the Koowa Framework (the framework
> behind Nooku)
> > >> > are welcome to sign the JCA and contribute their work to
> a branch and
> > >> > have it included in the core. It isn't our decision to
> make until it
> > >> > is sitting in a branch.
> >
> > >> > Sam Moffatthttp://pasamio.id.au <http://pasamio.id.au>
> <mailto:joomla-...@googlegroups.com>.
> > >> > > To unsubscribe from this group, send email to
> > >> joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com><joomla-dev-cms%2Bunsubscribe@go
> oglegroups.com <http://oglegroups.com>>
> > >> .
> > >> > > For more options, visit this group athttp://
> > >> groups.google.com/group/joomla-dev-cms?hl=en-GB
> <http://groups.google.com/group/joomla-dev-cms?hl=en-GB>.
> >
> > >> --
> > >> You received this message because you are subscribed to the
> Google Groups
> > >> "Joomla! CMS Development" group.
> > >> To post to this group, send an email to
> joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> > >> To unsubscribe from this group, send email to
> > >> joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com><joomla-dev-cms%2Bunsubscribe@go
> oglegroups.com <http://oglegroups.com>>
> > >> .
> > >> For more options, visit this group at
> > >>http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >
> > > --
> > > You received this message because you are subscribed to the
> Google Groups
> > > "Joomla! CMS Development" group.
> > > To post to this group, send an email to
> joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> > > To unsubscribe from this group, send email to
> > > joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com><joomla-dev-cms%2Bunsubscribe@go
> oglegroups.com <http://oglegroups.com>>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> --
> You received this message because you are subscribed to the
> Google Groups "Joomla! CMS Development" group.
> To post to this group, send an email to
> joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To post to this group, send an email to
> joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.
Looked very positive at the time, but it seems this has not been
picked up by 'the people in charge'.
On 9 apr, 16:26, Amy Stephen <amystep...@gmail.com> wrote:
> Good to see Ruud point out all the frameworks emerging. When Template
> Developers start to build applications on top of the application (kind
> of like an inside out framework), something is going on. One obvious
> possibility is that the application is no longer meeting the standard
> for current applications. A second possibility is that developers
> (including the Template folks) are positioning cross-CMS. To a certain
> extent, both are likely the cause.
>
> I agree with Torkil and Danayel that there is real value in working
> with Johan, and Mathias, and the other Nooku developers. Clearly,
> Nooku is superior to the Joomla! core framework in specific areas and
> we would be stupid not integrate those advantages into the core for
> everyone.
>
> Andy Miller's Gantry is another example of a framework, this one for
> Templates, that I think is certainly worthy of consideration in a 2.0
> Joomla! solution.http://www.gantry-framework.org/
> > > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
But again I say all of this discussion is wasted energy until 1.6 is
ready. Then perhaps we can define a true roadmap and take these
discussions further.
Framework discussions belong on the framework list and ideas etc
belong somewhere else, perhaps in the forums or perhaps on the sites
of the people whose code you are discussing.
If you are not posting about getting 1.6 to beta and stable then you
are posting in the wrong place.
Thank you for consideration to those who read this list because they
are working.
Elin
On Apr 9, 11:23 am, Ian MacLennan <ian.maclen...@joomla.org> wrote:
> It is reality. I'll see if I can get a copy posted soon.
>
> Thanks Phil.
>
> Ian
>
> On Fri, Apr 9, 2010 at 11:05 AM, Phil E. Taylor <p...@phil-taylor.com>wrote:
>
>
>
> > once again - is the JCA acutally a still "Request For Comment" or a
> > reality? - you speak like its the latter - but that has never been made
> > public - the last news on Joomla.org is a "Request For Comment" and no
> > post about the feedback or the coming into force.
>
> > The only public versions of the JCA are drafts and have DRAFT stamped
> > across them. Whats the text of the ones that are being used?
>
> > Transparency :-)
>
> > Kindest regards
> > Phil.
>
> > On 09/04/2010 15:53, Ian MacLennan wrote:
> > > All contributions from JXtended have been submitted by organizations and
> > > individuals who have signed the JCA.
>
> > > Ian
>
> > > 2010/4/9 klas berlič <klas.ber...@gmail.com <mailto:
> > klas.ber...@gmail.com>>
>
> > > As Nooku is GPL it can be used by anyone to incorporate it in GPL
> > > project as license allows it.
>
> > > But without JCA copyrights must be retained and that shouldn't be a
> > > problem as example case has been already done with larger code
> > > contribution by JExtended.
>
> > > Form administrator/com_comments/manifest.xml
> > > <copyright>Copyright (C) 2008 - 2009 JXtended, LLC. All rights
> > > reserved.</copyright>
>
> > > 2010/4/9 elin <elin.war...@gmail.com <mailto:elin.war...@gmail.com>>
> > > > >> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
> > > <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com<joomla-dev-cms%252Bun subs...@googlegroups.com>
> > ><joomla-dev-cms%2Bunsubscribe@go
> > > oglegroups.com <http://oglegroups.com>>
> > > > >> .
> > > > >> > > For more options, visit this group athttp://
> > > > >> groups.google.com/group/joomla-dev-cms?hl=en-GB
> > > <http://groups.google.com/group/joomla-dev-cms?hl=en-GB>.
>
> > > > >> --
> > > > >> You received this message because you are subscribed to the
> > > Google Groups
> > > > >> "Joomla! CMS Development" group.
> > > > >> To post to this group, send an email to
> > > joomla-...@googlegroups.com
> > > <mailto:joomla-...@googlegroups.com>.
> > > > >> To unsubscribe from this group, send email to
> > > > >> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
> > > <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com<joomla-dev-cms%252Bun subs...@googlegroups.com>
> > ><joomla-dev-cms%2Bunsubscribe@go
> > > oglegroups.com <http://oglegroups.com>>
> > > > >> .
> > > > >> For more options, visit this group at
> > > > >>http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> > > > > --
> > > > > You received this message because you are subscribed to the
> > > Google Groups
> > > > > "Joomla! CMS Development" group.
> > > > > To post to this group, send an email to
> > > joomla-...@googlegroups.com
> > > <mailto:joomla-...@googlegroups.com>.
> > > > > To unsubscribe from this group, send email to
> > > > > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
> > > <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com<joomla-dev-cms%252Bun subs...@googlegroups.com>
> > ><joomla-dev-cms%2Bunsubscribe@go
>
> ...
>
> read more »
@Wilco
My comment was not about the first post, though that should have been
on the framework list. Still a new poster may not know better, but
experienced people on this list should have basic mailing list
etiquette down by now.
Elin
> discussion to a different location <http://www.alltogetherasawhole.org/>.
>
> Regards, Wilco
>
> On Fri, Apr 9, 2010 at 5:23 PM, Ian MacLennan <ian.maclen...@joomla.org>wrote:
>
>
>
> > It is reality. I'll see if I can get a copy posted soon.
>
> > Thanks Phil.
>
> > Ian
>
> > On Fri, Apr 9, 2010 at 11:05 AM, Phil E. Taylor <p...@phil-taylor.com>wrote:
>
> >> once again - is the JCA acutally a still "Request For Comment" or a
> >> reality? - you speak like its the latter - but that has never been made
> >> public - the last news on Joomla.org is a "Request For Comment" and no
> >> post about the feedback or the coming into force.
>
> >> The only public versions of the JCA are drafts and have DRAFT stamped
> >> across them. Whats the text of the ones that are being used?
>
> >> Transparency :-)
>
> >> Kindest regards
> >> Phil.
>
> >> On 09/04/2010 15:53, Ian MacLennan wrote:
> >> > All contributions from JXtended have been submitted by organizations and
> >> > individuals who have signed the JCA.
>
> >> > Ian
>
> >> > 2010/4/9 klas berlič <klas.ber...@gmail.com <mailto:
> >> klas.ber...@gmail.com>>
>
> >> > As Nooku is GPL it can be used by anyone to incorporate it in GPL
> >> > project as license allows it.
>
> >> > But without JCA copyrights must be retained and that shouldn't be a
> >> > problem as example case has been already done with larger code
> >> > contribution by JExtended.
>
> >> > Form administrator/com_comments/manifest.xml
> >> > <copyright>Copyright (C) 2008 - 2009 JXtended, LLC. All rights
> >> > reserved.</copyright>
>
> >> > 2010/4/9 elin <elin.war...@gmail.com <mailto:elin.war...@gmail.com
> ...
>
> read more >>
--
Regards,
Andrew Eddie
> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
--
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
That said, I'd more than welcome an open peer review of the good, bad
and the ugly about it. But as said, let's get 1.6 out first. I'd also
draw your attention to the fact that we've put some effort into
reducing repeated code (see jcontrollerform, jmodellist, etc) so give
us some credit, eh? I'm happy to look at other suggestions but we need
to balaherewithhere we spend the most effort.
Regards,
Andrew Eddie
--
Regards,
Andrew Eddie
>> > >> > > <mailto:joomla-...@googlegroups.com>.
>> > >> > > To unsubscribe from this group, send email to
>> > >> joomla-dev-cm...@googlegroups.com
>> <mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.> > >> .
>> > >> > > < <http://groups.google.com/group/joomla-dev-cms?hl=en-GB>
Wilco's summary didn't say much except he envisioned for Joomla to be
doing what Koowa already does. So why not incorporate it? There still
hasn't been a single good reason not to make use of it yet.
He also seems to have confused Nooku, the language extension, with
Koowa, which is the framework it sits on and bundled them into one
thing which isn't the case.
Finally he announced that there are plans for a separate CMS at the
end of this year. I would love to know where this information came
from as I am on basically every Koowa mailing list and skype chat and
there has never been any serious discussion about releasing a Koowa
CMS. There have been a few jokes made various people (not Johan or
Mathias though that I recall) mainly because of the inadequacies of
the current J! fw. But this was just a red Herring to turn the
discussion away. If Hannes wishes to use this as a reason not to use
Koowa then -
1. I would like to see some evidence to back up this claim
2. It still doesn't preclude us using the fw for the benefit of the
community. I am sure simple pie is used in thousands of different
sites and projects. So even if there is a Koowa CMS due out at the end
of the year, the Joomla team should be smart enough to see that they
can still leverage the fw to advance Joomla by about 5-7 years worth
dev (given the current rate of fw development) in one shot. The whole
reason we use libraries like simple pie is to advance the project
without wasting time rewriting things that can be gotten elsewhere
(and are better)
As it was pointed out, if the current fw is fine the way it is, then
why are so many developers making or using their own frameworks?
Basically every major extension developer and template developer is
using some sort of framework on top of Joomla. Even Andrew Eddie has
his own slim framework for his extensions. When even core developers
are writing their own frameworks for their extensions it should be an
indication that things are not keeping up to speed with the
requirements of the community.
The J framework is good, but it's just not good enough given that day
and age we are in.
The biggest anti argument yet was that we should keep the core light
and not put too much in there. Koowa is a framework, and not an
extension that adds specific functionality (like content, contacts,
weblinks etc) so it would not bulk up the system functionality. On the
contrary it would mean that everything added to the core could be
lighter and with more code reuse.
Regardless, simply keeping something light shouldn't be used an excuse
for holding progress back. The end result is that every extension and
template front loads sites with their own frameworks to make up for
what's missing, meaning there are more problems, conflicts, slower
sites etc. Holding the core back will end up more "fat" sites than
picking a solid framework (or two e.g. koowa plus Gantry for
templates) and incorporating them into the core. There there will be
no need for every template company and extension company to write
their own.
@Elin - while it is debatable whether this should go here or not, it
has been started and it is heavily related to joomla development so we
should see it through rather than splitting or redirecting it away
from the official Joomla discussion areas and into a 3rd party site.
If we could move the post that would be best, but splitting it isn't
the answer I don't think.
In summary:
The current fw is good, but inadequate for current day development.
3pds are showing this with their feet and building their own.
(including core devs) having dozens of different fws cannot be good
for the community or for people building sites with J!. It should be
improved or replaced. Improvement, given the current pace of
development, would take years, and leave us with another framework
that was still years behind (though less so than the current one). So
we should pick the best of breed extension and template frameworks and
incorporate them into the core as libraries.
This would bring J! up to date almost overnight, and reduce the
confusion and bloat of having different fw's for every major extension
you install.
So the J! team needs to decide if they want to indirectly encourage
bloated heavy extension and redundant fw's by keeping the core fw as
it is, or encourage slim innovative extensions by bringing the fw up
to date.
> ...
>
> read more »
My question was suffixed with a question mark and was:
"is the JCA acutally a still "Request For Comment" or reality?"
I believe that has been answered in other replies. The answer is that
nothing has been announced or made public - however if one wants to
commit to 1.6 anything over 500 lines, on a case by case basis, then
they have to sign the JCA (but no one has said exactly what that current
document contains).
Oh, and apparently you can commit up to 500 lines without signing it! ?
strange that one but hey.
And its on a case by case basis at the moment - again strange - it
should be all or nothing.
But honestly though - I really dont care much for any of this :-)
Back to coding....
Kindest regards
Phil.
It is not appropriate for you to volunteer other people's code, and
that has nothing to do with licensing or whether it would be legal to
do so. It has to do with how you do professional and ethical
development within a GPL model. If you want to encourage one of the
template houses to offer its framework for the core (and who knows
maybe Andy is planning to include Gantry in his branch; I have no idea
what his plans are) please talk to them directly. It's not
appropriate to advocate grabbing people's work against their will--if
they want to contribute, just like you, just like the Nooku people,
just like Andy, just like any of the CCK folks-- they know where to
email asking for a branch.
Elin
I appreciate your answer. I would caution against taking any of our
comments as a criticism of core. What I hear (and feel) is just a
desire to help more in the community build ownership in the
development process, and cash in on some of the good stuff we already
have laying around. More and more your role and the role of the other
coordinators, will (hopefully) become more of a coordinator, teacher,
project manager. So, thanks for your positive response and all of your
effort getting us here.
Elin - I am wondering if you might have just had a bad day? I am not
certain if you are aware, but four times today, you inadvertently told
community to go away by telling them that they were not talking the
right way, or about the right stuff, or in the right location at the
right time. We really want to keep these types of friendly, positive,
organic community discussions going.
I thought Phil's question was a good one. He asked it in response to a
comment made by a Development Leadership Team member, he asked
politely, the topic is related to development, and the information is
something most of us are interested in. I am sorry to say this, but
your response to him in the other thread was not respectful.
I also agree with Danayel that this conversation *is* appropriate here
and I hope we try to encourage developers to talk here, rather than
push them off onto an off-property site. I think we'd agree that
discussing project topics off site doesn't always work well. We should
try to work together. Here, we can be together if we allow it.
Finally, I want to say that while I agree with you that the nooku devs
are talented and I also wish them luck, I really wish *us* luck - that
we might learn how to work together so that people don't go off and
take with them such massive talent and vision.
Like it or not, people are social, and before any commitment comes
interest, and a sense of belonging, and fun. I think we need to try to
allow a bit more leniency in allowing people to talk together and the
best place for a development community to collaborate is in the
development community list.
Elin - my comments are offered in respect as I appreciate your
considerable contributions to Joomla!.
Having said if the Development Leadership Team members shuffle us off
to the General list, we shouldn't feel pushed off if that happens. It
is important, as Elin says, to be more focused on list for only 1.6
tasks (but let's remember that natural conversation leads into
different - and interesting - places.)
All in all, though, I must say, this is an encouraging thread. I am
eager for our future together.
Amy
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
Boy does that come out of left yonder field. Who said Hannes was
doing anything. How about you regroup yourself Daniel and speak about
the facts instead of spreading crap. That statement is absolute crap,
you know it and I know it, and everyone knows it. Get real my
friend. When that happens then contribute reality to this
discussion. Enough with the theatrics.
> Finally he announced that there are plans for a separate CMS at the
> end of this year. I would love to know where this information came
> from as I am on basically every Koowa mailing list and skype chat and
> there has never been any serious discussion about releasing a Koowa
> CMS. There have been a few jokes made various people (not Johan or
> Mathias though that I recall) mainly because of the inadequacies of
> the current J! fw. But this was just a red Herring to turn the
> discussion away.
No one knows where Wilco gets his information because he didn't cite
where he got it or even if he has the authority to announce such an
idea. I suggest you ask Wilco to supply that information to this
list - if you want answers on this list. And again stop with the
theatrics. You want to know - ask the person who made the
statement. Don't hold everyone else accountable for it nor base the
rest of this rant you posted on it.
I am a big supporter of yours, but this just is beyond belief.
Jenny
> ...
>
> read more »
For Louis, and anyone else interested, you can get Nooku Framework
from here:
https://sourceforge.net/projects/nooku-framework/develop
> > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsu...@googlegroups.com>
I am sure that if you or a group want to work on any of those ideas
one of the development coordinators will give you a branch. Thank you
for making a substantive contribution towards a meaningful
conversation.
Elin
FYI this was in the text of Louis's blog
Who must sign the JCA before contributing?
Ideally, everybody who contributes to Joomla! or any other OSM
supported project would sign the JCA. But we are aware that some
contributors will not want to take the extra effort, especially for
one-time contributors of modest amounts of code. As a compromise, the
Joomla! Project requires a JCA from anybody who makes a significant
contribution to Joomla! or any other OSM project. "Significant" is,
of course, a judgment call. As a guideline, if you have more than 500
lines of code in the codebase, we need a JCA. Additionally, to be
granted commit access to our source code repository, we will need a
JCA.
In general a bug fix or a small number of totally original lines in a
codebase of about a million lines will not allow a contributor to
disrupt the project by demanding code be withdrawn, among other
things. 500 =about 0.05% of 1,000,000. Of course it's preferable to
have 100% coverage but it is not necessary. That is why the focus is
on major contributors of original code such as JXtended for comments
and current committers. This actually gives us a mechanism for taking
major contributions which is, in its obscure way, the topic of this
thread.
Elin
I thought not. :)
No one is stopping anyone from getting any positives or negatives from
either Joomla! or Nooku and/or offering/downloading anything at any
time when it comes to Nooku or Joomla! I think that clears it up
nicely.
Let's all tip a hat to Amy by stating - With deepest heartfelt
respect to all involved :)
Let's move along shall we?
Jenny
Have some respect people.
I personally have a vision for Joomla 1.7 and that vision includes some
core component rewrites, but not much more, so that 1.7 truelly can be
released half a year after 1.6. That said, I don't have huge framework
changes in mind for 1.7. However this is just my vision and what the
final outcome of 1.7 will be, is up to the community. If someone wants
to implement Koowa or just concepts of it into the Joomla framework,
he/she is invited to work on this in a branch and implement it there.
Then we can discuss about it here on the list like we did with the JForm
changes and the categories2 branch.
Hannes
As a developer, Nooku Framework for me is a improved and more
effective toolbox, than the Joomla Framework. From the outside it
seems weird that some people, like for instance Jennifer here, thinks
that it's the job of those who (imo!) drive innovation and improvement
in code in their own project, to set up a Joomla branch and try to
drag along those who can't seem to finish what they set out to do. Let
me correct myself: Not drag along, but spend time to TRY to drag along
and get things up to speed, while still risking that the code is just
turned down.
I've now read Andrew and Louis say that some parts about Nooku they
like and some parts they don't. With all due respect: That's the first
two people I've ever encountered that's both studied the Nooku FW 0.7
codebase AND found stuff in there they did NOT like. If you are to
improve the Joomla Framework, it's not always enough just to extend
it. Some pieces you just might have to replace. The code is good guys,
and there is an ever growing list of extensions out there to prove it.
You need to get over your egos and realize that someone outside the
core team is actually doing the stuff the core team should be doing.
Desperately trying to sit upright on that high horse of yours and
maintain positions is just making you look bad.
You have to chase and embrace innovation to stay in the game, not
demand that it comes over to shine your shoes.
On Apr 10, 7:53 am, Jennifer Marriott <marpomultime...@gmail.com>
wrote:
> Any arguments regarding the fact that people can get Nooku from the
> above mentioned by Torkil link -https://sourceforge.net/projects/nooku-framework/develop
Sorry for any confusion, and sorry to Hannes. It might have been nice
to confirm before letting both barrels go at me though.
As for asking the person who made the statement, that is exactly what
I was doing "I would love to know where this information came from..."
Sorry again for the confusion. Let me rephrase.
Wilco, where did you get our information, because I have never heard
such a thing, and even when I asked Johan directly he said they had
absolutely no plans for a new Koowa CMS.
@Elin - Did the other libraries volunteer their code themselves?
simple pie etc? (just curious, not picking a fight)
I "offerred" Koowa because both Johan and Mathias have said to me they
would be delighted to see it in the core.
But more than offering I was suggesting that a couple of frameworks be
chosen and approached about being in the core.
Even if I was suggesting just taking it without asking, both are free,
GPL, publicly available, and the developers themselves are encouraging
as many people as possible to make use of them. There is nothing
unethical at all about it. Both developers (koowa + gantry) are former
core team developers who make their living with joomla. Why would they
-not- want to see their framework as the standard for the project they
have given so much too and gotten so much from?
And even if both of them refused outright. It still doesn't remove the
point that the Joomla framework is falling behind current expectations
at an ever increasing rate and something should be done because it is
bad for the project and the community to have dozens of different
frameworks "patching" up the core for things that should be in there.
Using this strawman argument as a reason not to give the framework a
re-think doesn't do any justice to anyone.
My main point is not that Koowa or Gantry specifically should be in
the core, but that the current framework needs a rethink, and a best
of breed could and should be picked from the community, as the work is
already mostly done, and then that used to bring the core framework up
to date. K and G were only my examples because I personally feel they
are the best of breed.Though I am sure others will dissagree.
To keep denying that anything is wrong is keeping one's head in the
sand. Because if the current fw was adequate then why is pretty much
every major developer writing or using a different framework?
If everyone is carrying an open umbrella, it's a pretty good
indication that it is raining.
Now, this is not to criticize specific people or the work and effort
that people put in, which is huge I know. But that work could be
better directed by "outsourcing" the fw, in the same way that we have
outsourced with tiny mce, simple pie and so on.
> > > > > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
Joomla! has systematically taken an approach of reducing its
dependence upon external libraries where possible. This will become
immediately apparent when you realise that the libraries folder is
reduced in 1.6 - Johan was himself in fact the biggest proponent of
removing external frameworks and once kindly explained it to me. One
of historically the issues that was taken was an over reliance on
external code not appropriately suited to the framework and then the
support of those libraries either going in directions opposite to what
we are doing or not being supported at all. In Johan's words there was
a "library shopping spree" which turned out to be more detrimental to
the project before Joomla!.
Koowa, Nooku Framework, what ever they call it this month is welcome
to be integrated. They extend, replace and add to various parts of the
Joomla! Framework. JXtended did the same thing in both 1.0 and 1.5
which has made it into the Joomla! Framework and I thank them for
their contributions. I'd like to invite them to do the same that
JXtended has done and integrate their improvements into the code base,
add to classes, add improvements, perhaps replace entire classes.
As always, if you want a branch to put code into, just let me know and
I can arrange access.
Sam Moffatt
http://pasamio.id.au
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
@Louis - I don't know if you have magical powers, or not, but not long
after I read your note inquiring on the public availability of Koowa,
Johan opened the Nooku developer portal. http://twitter.com/nooku/status/11939667480
So, it will be good for those who have not played with it, yet, to
take a look.
@Torkil - for me, this is not an either or kind of thing where we
should even consider unplugging one framework and plugging in the
other. That *would* be an ego thing since there are clearly advantages
in the 1.6 framework that I want available, too, and things I also
like better in Koowa. The point is that the project must be open to
everyone to participate and we should consider interesting solutions
emerging from the entire global developer community.
I am very comfortable with the responses we heard from Andrew, Sam,
Louis and Hannes. I briefly spoke with Johan and he also seemed
pleased with this open community discussion and the various
viewpoints. So, from my perspective, the door is open and anyone who
wants to collaborate as a community is able to do so. From there, it's
up to each individual developer to consider what works best for their
goals and ambitions and to jump in or continue on more focused tracks.
It's fair to say you gotta jump in to be involved, but that goes
without saying.
On Apr 10, 11:02 am, Louis Landry <louis.lan...@joomla.org> wrote:
> Torkil,
>
> My response has nothing to do with my ego. I really have no idea where you
> come off saying that to be honest. Your statement that "first two people
> I've ever encountered that's both studied the Nooku FW 0.7 codebase AND
> found stuff in there they did NOT like" to me speaks more to there not being
> enough high level developers actually studying the codebase -- or that you
> just haven't encountered them. There are NO frameworks out there in any
> language, on any platform, or with any significant purpose that some
> developers don't find flaw in. Software is as much art as it is math.
>
> You also seem to be putting words or thoughts into my head about the way the
> Joomla Framework is to be improved. Have Andrew or I ever said anywhere
> that we only want to extend the framework and not replace parts of it? I am
> fairly certain I never said anything like that. I have in fact replaced
> some parts of the framework in the 1.6 trunk for example. You are also
> welcome to take a stab at replacing another part if you believe you can make
> it better -- just like anyone else including Johan and anyone else at
> Joomlatools.
>
> - Louis
>
> ...
>
> read more »
--
On 10 Apr, 20:33, dukeofgaming <dukeofgam...@gmail.com> wrote:
>
> An example of the point I'm trying to make is the PHP Traits and Grafts RFC:
>
> http://wiki.php.net/rfc/traits
>
> In order to take such
> ideas/examples into account for the specific case of Joomla, I think each
> seriously taken proposed feature should have a case made, so that our core
> devs can just say "it makes sense, we can include it at certain point" or
> "the idea needs more work" and even "here are our ideas/work/intentions so
> far on the subject", instead of debating others' absolutes.
>
> Its not just code what's on the line here. Changes and additions to Joomla
> should not be taken lightly, and I mean it for both suggesting and
> discarding them. Suggesting sometimes turns into demanding (citing the case
> of JQuery and this case itself), and discarding sometimes just means
> unnoticing.
>
David -
That was a well thought out summary of where we are at - and it
included an excellent approach and rationale that could help us
overcome these challenges.
I hope everyone reads this post and takes a look at the link, as well.
It's very easy to walk in and "demand" something, like jQuery. It's
also pretty easy to say "No. We use Mootools." But neither settles the
issue. (Even those with the keys to the SVN don't really have the
final say since, as you have correctly pointed out, the issue
resurfaces on a regular basis.)
In many ways, it's time for the project to stop saying no and begin
asking how?
Returning to the jQuery issue, a number of good ideas were presented
by developers to create a framework that allowed variations without
conflict. (If I remember correctly, you shared some very interesting
specs, even tho you prefer Mootools). We really should encourage
people to solve their problems and provide a way for them to describe
their ideas, using drawings and code examples, etc., and involve
others in the process.
Then, as people's crazy dreams start evolving into workable solutions,
those overseeing the core could provide feedback and guide the effort,
either towards inclusion in core or as a community-wide/project
supported extension. (Maybe the process would always call for first
use as an extension and then possible inclusion as core if successful
and broadly needed.)
If we stop saying "no" (which is what creates all this drama), and
instead point to the process we use to introduce and develop your
idea, then the door stays open and the expectation to scratch your own
itch is in place. Thinking out loud, here, it might also make sense to
allow non-coders chip in to a bounty so that it's still clear - no one
is saying no to you - you can pay to have this done, too, and here is
the process we have provided to make it easier for you to do so.
Most open source project "how to" guides talk about documenting these
types of issues so that the developers time is not wasted re-
explaining earlier issues. What you are suggesting not only fits into
that category, but it also goes much further into empowering community
to solve their problems and help create the right expectations about
how these things work without creating pressure on the project or
unnecessary drama.
As it always is, the real challenge is someone agreeing to spearhead
the effort so that it's then available to use. It will be good to hear
what the developer team thinks about this, and it might be that Chris
Davenport (the documentation lead) has considered these issues, as
well. This might be something that fits into that category, anyway.
I really think you are on to something and I appreciate you sharing
that idea.
Amy
Things might have been ignored which is unfortunate but it is also
life. Everyone is busy and sometimes they need a reminder. At work I
have a two month lead time on jobs getting done by our system
administrators. If something has been dropped between the crack people
(myself included) might need reminding. We're far from perfect and I'm
the first to admit it but we're trying to get there.
And to be honest I have no issues with you setting up an RFC area on
the wiki and posing it for discussion here. It should be discussed and
improved by everyone who has an interest in building it. RFC's
realistically take a while as you're saying so there is no harm in
starting the process now with your ORM project.
But perhaps I wonder if we're going the wrong way, thinking about this
the wrong way. I wonder if we're asking the wrong question. We're
asking about building an ORM library, including the Nooku library,
including the JXtended library (which is really integrated into the
core Joomla namespace) and having it included in the core
distribution. This sooner or later makes things chunky, especially
when none of the core depends on them. To be honest there is nothing
stopping anyone shipping libraries that run with Joomla! and do their
own thing. I have myself my own set of libraries for Joomla! but I
don't think it'd be appropriate to include them even though I could.
To be honest there are times when I wonder what this obsession is with
putting all of this stuff in core. Why not build something awesome, do
it right, release it out there and then get it included. Why this
insistence upon waiting for it to be approved to go into core before
building things? If it is good, build it, put it out there and see if
people are using it. In some respects this is what Nooku are doing and
we're having this conversation but as you can tell, I'm wondering
about that as well.
Additionally being included in the core means is that you're tied to
the core's timeframes. This can make life hard. For my own projects
there are those which I feel should be in core like the update stuff
but almost everything else I do I feel should live outside. If I want
to add a new feature or similar I'm not tied to the next major release
or similar - I can just do it.
What I'd love to see is more people take this up. We eventually pull
stuff out of core, shift more towards building distributions with off
the shelf components, in 1.7 I want to build a really awesome
dependency manager (I didn't get around to it for 1.6) so that this
just happens. You want to install a component and it requires Nooku
Framework, that is fine it is handled. Move towards a model like the
Debian with its package manager systems. I've wanted to get here for a
while but haven't had the chance. If anything I feel it is the most
important thing out there. Rebuilding the way com_content works? Sure,
wonderful, but someone else can do that. Making a kick arse
installer/updater/package manager/automatic backup engine/tool for
global domination? Someone else could do it but until it is in core
nobody can really depend upon it.
But at the end of the day we need to step back an objectively look at
what the core needs and what people could do better. There are tonnes
of CCK solutions out there for Joomla! now and there are some people
who think this is a problem. Libraries like Nooku Framework I don't
see as a problem or even particularly needing to be included in core.
If you look at a modern operating system there are many different
libraries each duplicating the same functionality. If you look at the
core of an operating system, the kernel, in some cases there are moves
to shift stuff out. User space file systems stands as something in my
mind that demonstrates something traditionally very much in the realm
of the kernel being moved out into user space.
So whilst I'd love to see the Nooku guys integrate Nooku into the
Joomla! libraries and have that discussion here, they're off building
their framework their way. And you know what, I think that is cool and
healthy. I think it is great for them to do that and make it available
to the Joomla! community, they come along to JoomlaDay and talk about
their framework and if it results in better Joomla! extensions then it
is great.
And I'd like to echo Louis' sentiments. Never is there anything that
people completely agree or disagree with. Not just in frameworks but
in operating systems, application design, systems integration and much
more. There is always a decision that one might disagree with, I
personally like to call them "curious" decisions - ones that I might
not make myself but aren't necessarily wrong. Take for example
Windows's security model, it is perhaps the most robust and advanced
of the security models for file systems out there. It is the basis of
NFSv4 ACL's which itself is source for Mac OS X and ZFS ACL's. But it
also has the change notify privilege which subverts the security
protections you get from traverse checking. That is a curious decision
and a performance vs security trade off in addition to the fact the
same SeChangeNotifyPrivilege control change notifications AND enables
bypass traverse checking, but it is an approach they've taken.
At the end of the day we can't possibly hope to stuff everything in
core. We've seen that in the past and it doesn't bode well.
Sam Moffatt
http://pasamio.id.au
Please test.
--
Merci de ne pas renvoyer de pièces attachées automatiquement.
------------------
Jean-Marie Simonet/infograf
> infog...@orange.frhttp://www.info-graf.fr
>
> killing_archives.patch
> 34KWeergevenDownloaden
I think it's the other way around, we need to adjust to accommodate
the archive state in other components. It's part of building
consistency across all of the content. Even with no front end layouts
it is highly useful go have the archive state for the back end and to
handle older items in searching while keeping them out of lists. We
never had archive for anything besides content before as far as I
remember.
Elin
Hannes
JM,
I think it's the other way around, we need to adjust to accommodate
the archive state in other components. It's part of building
consistency across all of the content. Even with no front end layouts
it is highly useful go have the archive state for the back end and to
handle older items in searching while keeping them out of lists. We
never had archive for anything besides content before as far as I
remember.
Elin
On Apr 11, 3:50 pm, Gerlof <gerl...@gmail.com> wrote:
> It looks like you accidentally changed the subject of this
> discussion... ;)
>
> On 11 apr, 20:44, JM Simonet <infograf...@gmail.com> wrote:
>
>
>
> > Looks like that's an oldie remaining from past code.
> > The feature is not implemented and we have
> > toolbars and code snippets + strings for the
> > comps in banners, redirect, weblinks, newsfeeds,
> > categories, ·
> > I implemented this change in jean_marie branch.
> > Find a patch attached.
> > Ready to go as this is quite trivial.
>
> > Please test.
> > --
> > Merci de ne pas renvoyer de pièces attachées automatiquement.
> > ------------------
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
--
Please keep the Subject wording in your answers
Each PEP should have the following parts:
Preamble -- RFC 822 style headers containing meta-data about the PEP, including the PEP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.
Abstract -- a short (~200 word) description of the technical issue being addressed.
Copyright/public domain -- Each PEP must either be explicitly labelled as placed in the public domain (see this PEP as an example) or licensed under the Open Publication License [7].
Specification -- The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Python platforms (CPython, Jython, Python .NET).
Motivation -- The motivation is critical for PEPs that want to change the Python language. It should clearly explain why the existing language specification is inadequate to address the problem that the PEP solves. PEP submissions without sufficient motivation may be rejected outright.
Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
Backwards Compatibility -- All PEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The PEP must explain how the author proposes to deal with these incompatibilities. PEP submissions without a sufficient backwards compatibility treatise may be rejected outright.
Reference Implementation -- The reference implementation must be completed before any PEP is given status "Final", but it need not be completed before the PEP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.
The final implementation must include test code and documentation appropriate for either the Python language reference or the standard library reference.
PEP Header PreambleEach PEP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.PEP: <pep number>Title: <pep title>Version: <svn version string>Last-Modified: <svn date string>Author: <list of authors' real names and optionally, email addrs>* Discussions-To: <email address>Status: <Draft | Active | Accepted | Deferred | Rejected |Withdrawn | Final | Replaced>Type: <Standards Track | Informational | Process>* Content-Type: <text/plain | text/x-rst>* Requires: <pep numbers>Created: <date created on, in dd-mmm-yyyy format>* Python-Version: <version number>Post-History: <dates of postings to python-list and python-dev>* Replaces: <pep number>* Replaced-By: <pep number>
Then, as people's crazy dreams start evolving into workable solutions,
those overseeing the core could provide feedback and guide the effort,
either towards inclusion in core or as a community-wide/project
supported extension. (Maybe the process would always call for first
use as an extension and then possible inclusion as core if successful
and broadly needed.)
> I'd like to think that what I am proposing would be different from the call
> for white papers that was organized back in 2008 to a more diluted, long
> lasting and less time consuming approach so that the team can review ideas
> when they really reach a state of evolution where they are drama-free.
>
> Well detailed ideas that the community can constantly enrich, not wishlists.
>
> Perhaps it would be more like Python's PEPs (
> http://www.python.org/dev/peps/pep-0001/):
Excellent idea. That would make the discussion and decision process
transparent to everyone. The state and maturity of the proposals would
automagically make up a reliable roadmap.
Niels
--
A new thread is an excellent idea.
On Apr 14, 11:40 am, Louis Landry <louis.lan...@joomla.org> wrote:
> David,
>
> I really like where you are going with this train of thought. Perhaps it
> would be more useful to lift it out of a thread that has probably run its
> course and lets see if we can find a way to distill some action items out of
> it. What of what are you proposing are you willing to head up and see
> through? What of what you are proposing do you see as being needed from
> leadership or project resources? What do you envision as next steps? Let's
> look at working through those things ... and probably in a new thread so it
> can have the focus it deserves.
>
> - Louis
>
> On Mon, Apr 12, 2010 at 2:06 AM, dukeofgaming <dukeofgam...@gmail.com>wrote:
>
> > Well, the problem I see is that even when good debate is done and ideas
> > arise they are not really that easy to rescue afterwards; people keep coming
> > with the same inquiries. I bet someone will come again asking for the Nooku
> > framework to be matched by or incorporated to Joomla... its not like Nooku
> > is getting any less popular, same case for jQuery (and I'm all for
> > Mootools).
>
> > I'd like to think that what I am proposing would be different from the call
> > for white papers that was organized back in 2008 to a more diluted, long
> > lasting and less time consuming approach so that the team can review ideas
> > when they really reach a state of evolution where they are drama-free.
>
> > Well detailed ideas that the community can constantly enrich, not
> > wishlists.
>
> > Perhaps it would be more like Python's PEPs (
> >http://www.python.org/dev/peps/pep-0001/):
>
> > [image: pep-0001-1.png]
> > (If the image above isn't shown, here is the URL:
> >http://www.python.org/dev/peps/pep-0001/pep-0001-1.png)
>
> > Each PEP should have the following parts:
>
> >> 1.
>
> >> Preamble -- RFC 822 <http://www.faqs.org/rfcs/rfc822.html> style
> >> headers containing meta-data about the PEP, including the PEP number, a
> >> short descriptive title (limited to a maximum of 44 characters), the names,
> >> and optionally the contact info for each author, etc.
> >> 2.
>
> >> Abstract -- a short (~200 word) description of the technical issue
> >> being addressed.
> >> 3.
>
> >> Copyright/public domain -- Each PEP must either be explicitly labelled
> >> as placed in the public domain (see this PEP as an example) or licensed
> >> under the Open Publication License<http://www.opencontent.org/openpub/>
> >> [7] <http://www.python.org/dev/peps/pep-0001/#id16>.
> >> 4.
>
> >> Specification -- The technical specification should describe the
> >> syntax and semantics of any new language feature. The specification should
> >> be detailed enough to allow competing, interoperable implementations for any
> >> of the current Python platforms (CPython, Jython, Python .NET).
> >> 5.
>
> >> Motivation -- The motivation is critical for PEPs that want to change
> >> the Python language. It should clearly explain why the existing language
> >> specification is inadequate to address the problem that the PEP solves. PEP
> >> submissions without sufficient motivation may be rejected outright.
> >> 6.
>
> >> Rationale -- The rationale fleshes out the specification by describing
> >> what motivated the design and why particular design decisions were made. It
> >> should describe alternate designs that were considered and related work,
> >> e.g. how the feature is supported in other languages.
>
> >> The rationale should provide evidence of consensus within the
> >> community and discuss important objections or concerns raised during
> >> discussion.
> >> 7.
>
> >> Backwards Compatibility -- All PEPs that introduce backwards
> >> incompatibilities must include a section describing these incompatibilities
> >> and their severity. The PEP must explain how the author proposes to deal
> >> with these incompatibilities. PEP submissions without a sufficient backwards
> >> compatibility treatise may be rejected outright.
> >> 8.
> > - For the jQuery and Mootools thing,:
> > - Make Joomla library agnostic through a javascript framework:
> > Possibly under discussion, rejected or superceded by the following.
> > - Loose the dollar function at core implementation to make Mootools
> > less conflicting: Possibly accepted
> > - Implement Object Oriented jQuery integration with Mootools (
> > http://ryanflorence.com/object-oriented-jquery-with-mootools-pigs-tak...
> > Possibly under discussion and on the verge of acceptance.
> > - With the ORM matter, we could have had the following ones:
> > - Integrate Doctrine: possibly rejected, but everybody would know
> > why and wouldn't suggest it again.
> > - Implement an ORM library: Possibly accepted and the features would
> > have been already delimited.
>
> > By the way... at this point I don't even know if an ORM is something
> > that Joomla desires, so I just ceased trying to contribute to the idea a
> > while ago.
> > - In this case, with the Nooku framework, we could have already started
> > to decide what we want from it, or any other framework.
> > - Same goes for a CCK.
> > - Same goes for article translations.
> > - Same goes for the excellent package manager ala Debian you are
> > On Sun, Apr 11, 2010 at 9:36 AM, Sam Moffatt <pasa...@gmail.com> wrote:
>
> >> We did have a formal RFC or papers process for 1.6 and we poured
> >> through them all and for the most part they ended up being wishlist
> >> requests with very few people actually turning up to build the code.
> >> We might have one again for 1.7 when we're done with 1.6 and it might
> >> work better then with things but at this point in time an RFC process
>
> ...
>
> read more »