You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2009/04/01 14:44:41 UTC
No more Java 7: Move to PHP, .Net or something else?
Hi everyone,
you might have noticed (e.g. via the blog post [1] which gained a lot of
publicity) that the future of Java is very uncertain. Maybe the next
version won't be an open standard anymore.
I think we should seriously consider migrating to another platform. I'm
sure there must be good reasons that most CMS's are written in PHP
anyway. There are some quite powerful frameworks (Zend, PEAR) to
implement complex web applications. Combined with a mature JavaScript
library like Dojo or YUI we could create a productive system in an
acceptable timeframe. I think moving to PHP would also help to increase
the potential user base.
BTW, recently I did a project using .Net, and I was very positively
suprised and think it would be a viable alternative. We could finally
get rid of those endorsed libraries issues and of all our legacy code.
Maybe there are other platforms worth considering? E.g. Ruby on Rails?
[1] http://www.jroller.com/scolebourne/entry/no_more_java_7
WDYT? Any comments are greatly appreciated!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Michael Wechner <mi...@wyona.com>.
Thomas Comiotto schrieb:
>>
>> With all respect, but this seems to me a very paranoid suggestion.
>>
>
> You might want to check today's date.
indeed, well-done :-)
feeling stupid indeed :-)
... but nevertheless sad :-(
Cheers
Michael
>
> Cheers
> Thomas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Andreas Hartmann <an...@apache.org>.
rudolf.korhummel@uniklinik-freiburg.de schrieb:
[…]
> Was it the first april's fool on an apache mailinglist ?
No, there were some nice ones before, e.g. on the Sling list:
http://www.mail-archive.com/sling-dev@incubator.apache.org/msg03697.html
http://www.mail-archive.com/sling-dev@incubator.apache.org/msg09262.html
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by ru...@uniklinik-freiburg.de.
Vik Tara <vi...@propco.co.uk> schrieb am 02.04.2009 14:07:21:
> I think we all got suckered there :)
>
Yes, but a very nice idea from Andreas I think ;)
Thanks for the fun !
Was it the first april's fool on an apache mailinglist ?
Rudolf
>
> Thorsten Scherler wrote:
> > On Wed, 2009-04-01 at 22:10 +0200, Thomas Comiotto wrote:
> >>> With all respect, but this seems to me a very paranoid suggestion.
> >>>
> >> You might want to check today's date.
> >
> > lol
> >
> > joder, you got me as well. ;)
> >
> > salu2
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Vik Tara <vi...@propco.co.uk>.
I think we all got suckered there :)
Thorsten Scherler wrote:
> On Wed, 2009-04-01 at 22:10 +0200, Thomas Comiotto wrote:
>>> With all respect, but this seems to me a very paranoid suggestion.
>>>
>> You might want to check today's date.
>
> lol
>
> joder, you got me as well. ;)
>
> salu2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2009-04-01 at 22:10 +0200, Thomas Comiotto wrote:
> >
> > With all respect, but this seems to me a very paranoid suggestion.
> >
>
> You might want to check today's date.
lol
joder, you got me as well. ;)
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
Open Source Java <consulting, training and solutions>
Sociedad Andaluza para el Desarrollo de la Sociedad
de la Información, S.A.U. (SADESI)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Thomas Comiotto <th...@id.uzh.ch>.
>
> With all respect, but this seems to me a very paranoid suggestion.
>
You might want to check today's date.
Cheers
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Learning from Yanel?
Posted by Michael Wechner <mi...@wyona.com>.
Joachim Wolfgang Kaltz schrieb:
> Hi Michi
>
> thanks for your insights. There are several issues here and I'm still
> trying to sort them out ;)
>
> 1. Design principles
> Do I understand correctly: your resource objects say which interfaces, in
> which version, they implement. Does that mean that you store this
> information along with the contents?
no. There is a dedicated "repository" containing the resource type
configurations. One can either do a one-to-one mapping, for example
/foo/bar.html
is mapped to
/foo/bar.html.yanel_rc (whereas this is an XML containing all the
relevant resource type configuration)
or use a map (also an XML containing patters)
/*.html
is mapped to
xhtml.yanel_rc
for example.
So the chain of responsibility is to check first if there exists a
one-to-one mapping and if not then will check the map which contains
patterns which might match.
(similar to Lenya which checks "first" the doctype, but I would say
more general)
> If so, is it in XML,
resource configurations are in XML
> or serialized
> Java objects, or ... (just being curious ;) )
> So next step, you read a resource and the controller knows which version
> of which interface this resource implements. If you keep the "old" code in
> your controller to support the older versions of the interfaces, you can
> handle them.
>
the core will ask the resource (which handles a specific request) which
interface version it implements and hence will handle it accordingly
> 2. Consequences
> I understand how this would simplify backwards compatibility, since the
> old code is still in the program and still works. But why would this
> result in less releases being necessary?
>
because you don't need any releases anymore re the core itself (only the
versioned interfaces are released, and as soon as they are, they will be
carved in stone).
So one can do real continuous integration with the core itself
> 3. Relevancy to Lenya
> Do you see an incompatibility between this approach and what Lenya is
> doing?
I am not sure if I understand your question, because I would consider
the core architecture re the resources of Yanel very different than how
Lenya generates/handles content.
If your question is "what needs to be changed that Lenya can also
support versioned interfaces", then I would say "let's first define what
the current interfaces of Lenya are at the moment"
> Is there something inherent in Lenya's design which would prohibit
> versioned interfaces?
I guess the question would be what are the current interfaces of Lenya?
> At the moment, an argument that comes to my mind
> would be that the interfaces in Lenya are too complex and would make the
> implementation of versioned interfaces too hard to maintain - is this the
> main problem in your eyes, or something else?
>
I don't think the number is the problem, but I would say that Lenya has
many interfaces which are not spelled out as interfaces, but
still people build something on top of them and developers are suddenly
changing them and everybody is suddenly surprised that they
are facing an upgrade nightmare. This is what I have experienced many
times and Lenya is not the only CMF/S with this problem and this is
what we IMHO really solved with Yanel.
Cheers
Michael
> Thanks in advance for any further input!
>
> Wolfgang
>
>
>>>> (...)
>>>> The main reasons I have started Yanel and use it today successfully
>>>> (and
>>>> not using Lenya anymore) are
>>>>
>>>> - backwards compatibility/upgradeability
>>>> - scalability/performance
>>>> (...)
>>>>
>>>> With Yanel we do not need releases anymore (except from a marketing
>>>> point of view), but can continuously upgrade at any time and it handles
>>>> arbitrary amount of content without a problem
>>>>
>>>>
>>> Hi Michi
>>> IIUC you are saying that Yanel has design principles ensuring
>>> upgradeability. This sounds interesting, can you elaborate a bit?
>>>
>>>
>> it's all about versioned interfaces
>>
>> http://yanel.wyona.org/javadoc/org/wyona/yanel/core/api/attributes/package-summary.html
>>
>> Yanel is at the core a framework with interfaces (with content
>> management characteristics) in order to build on.
>>
>> Interfaces/contracts/protocols have a good and bad side. Your
>> implementations break when they are being changed, but
>> you want them to break. So how to get out of this dilemma?
>>
>> The answer is "versioned interfaces" (just as some protocols also have a
>> version)
>>
>> So the basic element/unit of Yanel is a so-called "resource" (or
>> "resource type"), which acts as controller, but has no capabilities in
>> the first place. Each request is mapped onto such a resource type
>> instance (similar as in Cocoon each request is mapped onto a pipeline).
>>
>> Now a resource type can become some life by applying some interfaces,
>> such as for example, viewable, modifiable, etc.
>>
>> These interfaces are versioned and the core of Yanel checks the versions
>> and handles them accordingly.
>>
>> Very simple and it works great :-)
>>
>> This way you can upgrade at any time without a problem.
>>
>> HTH
>>
>> Michael
>>
>>> TIA
>>> Wolfgang
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>>> For additional commands, e-mail: dev-help@lenya.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>> For additional commands, e-mail: dev-help@lenya.apache.org
>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Learning from Yanel?
Posted by Joachim Wolfgang Kaltz <jo...@uni-due.de>.
Hi Michi
thanks for your insights. There are several issues here and I'm still
trying to sort them out ;)
1. Design principles
Do I understand correctly: your resource objects say which interfaces, in
which version, they implement. Does that mean that you store this
information along with the contents? If so, is it in XML, or serialized
Java objects, or ... (just being curious ;) )
So next step, you read a resource and the controller knows which version
of which interface this resource implements. If you keep the "old" code in
your controller to support the older versions of the interfaces, you can
handle them.
2. Consequences
I understand how this would simplify backwards compatibility, since the
old code is still in the program and still works. But why would this
result in less releases being necessary?
3. Relevancy to Lenya
Do you see an incompatibility between this approach and what Lenya is
doing? Is there something inherent in Lenya's design which would prohibit
versioned interfaces? At the moment, an argument that comes to my mind
would be that the interfaces in Lenya are too complex and would make the
implementation of versioned interfaces too hard to maintain - is this the
main problem in your eyes, or something else?
Thanks in advance for any further input!
Wolfgang
>>> (...)
>>> The main reasons I have started Yanel and use it today successfully
>>> (and
>>> not using Lenya anymore) are
>>>
>>> - backwards compatibility/upgradeability
>>> - scalability/performance
>>> (...)
>>>
>>> With Yanel we do not need releases anymore (except from a marketing
>>> point of view), but can continuously upgrade at any time and it handles
>>> arbitrary amount of content without a problem
>>>
>>
>> Hi Michi
>> IIUC you are saying that Yanel has design principles ensuring
>> upgradeability. This sounds interesting, can you elaborate a bit?
>>
>
> it's all about versioned interfaces
>
> http://yanel.wyona.org/javadoc/org/wyona/yanel/core/api/attributes/package-summary.html
>
> Yanel is at the core a framework with interfaces (with content
> management characteristics) in order to build on.
>
> Interfaces/contracts/protocols have a good and bad side. Your
> implementations break when they are being changed, but
> you want them to break. So how to get out of this dilemma?
>
> The answer is "versioned interfaces" (just as some protocols also have a
> version)
>
> So the basic element/unit of Yanel is a so-called "resource" (or
> "resource type"), which acts as controller, but has no capabilities in
> the first place. Each request is mapped onto such a resource type
> instance (similar as in Cocoon each request is mapped onto a pipeline).
>
> Now a resource type can become some life by applying some interfaces,
> such as for example, viewable, modifiable, etc.
>
> These interfaces are versioned and the core of Yanel checks the versions
> and handles them accordingly.
>
> Very simple and it works great :-)
>
> This way you can upgrade at any time without a problem.
>
> HTH
>
> Michael
>> TIA
>> Wolfgang
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>> For additional commands, e-mail: dev-help@lenya.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Learning from Yanel?
Posted by Michael Wechner <mi...@wyona.com>.
Joachim Wolfgang Kaltz schrieb:
>> (...)
>> The main reasons I have started Yanel and use it today successfully (and
>> not using Lenya anymore) are
>>
>> - backwards compatibility/upgradeability
>> - scalability/performance
>> (...)
>>
>> With Yanel we do not need releases anymore (except from a marketing
>> point of view), but can continuously upgrade at any time and it handles
>> arbitrary amount of content without a problem
>>
>
> Hi Michi
> IIUC you are saying that Yanel has design principles ensuring
> upgradeability. This sounds interesting, can you elaborate a bit?
>
it's all about versioned interfaces
http://yanel.wyona.org/javadoc/org/wyona/yanel/core/api/attributes/package-summary.html
Yanel is at the core a framework with interfaces (with content
management characteristics) in order to build on.
Interfaces/contracts/protocols have a good and bad side. Your
implementations break when they are being changed, but
you want them to break. So how to get out of this dilemma?
The answer is "versioned interfaces" (just as some protocols also have a
version)
So the basic element/unit of Yanel is a so-called "resource" (or
"resource type"), which acts as controller, but has no capabilities in
the first place. Each request is mapped onto such a resource type
instance (similar as in Cocoon each request is mapped onto a pipeline).
Now a resource type can become some life by applying some interfaces,
such as for example, viewable, modifiable, etc.
These interfaces are versioned and the core of Yanel checks the versions
and handles them accordingly.
Very simple and it works great :-)
This way you can upgrade at any time without a problem.
HTH
Michael
> TIA
> Wolfgang
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Learning from Yanel?
Posted by Joachim Wolfgang Kaltz <jo...@uni-due.de>.
> (...)
> The main reasons I have started Yanel and use it today successfully (and
> not using Lenya anymore) are
>
> - backwards compatibility/upgradeability
> - scalability/performance
> (...)
>
> With Yanel we do not need releases anymore (except from a marketing
> point of view), but can continuously upgrade at any time and it handles
> arbitrary amount of content without a problem
Hi Michi
IIUC you are saying that Yanel has design principles ensuring
upgradeability. This sounds interesting, can you elaborate a bit?
TIA
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann schrieb:
> Hi everyone,
>
> you might have noticed (e.g. via the blog post [1] which gained a lot
> of publicity) that the future of Java is very uncertain. Maybe the
> next version won't be an open standard anymore.
>
> I think we should seriously consider migrating to another platform.
With all respect, but this seems to me a very paranoid suggestion.
There are a lot of Java based applications and very big companies are
using these applications and you might also
want to consider
http://online.wsj.com/article/SB123735970806267921.html
and last but not least there is
http://harmony.apache.org/
I am not saying that there won't be any problems in the future, but I
don't think there is any reason to panic
> I'm sure there must be good reasons that most CMS's are written in PHP
> anyway.
yes, there are good reasons. PHP provides a fast learning curve and
everyone thinks another CMS is needed, but that doesn't mean anything at
all!
> There are some quite powerful frameworks (Zend, PEAR) to implement
> complex web applications. Combined with a mature JavaScript library
> like Dojo or YUI we could create a productive system in an acceptable
> timeframe. I think moving to PHP would also help to increase the
> potential user base.
Bullshit!!! The problems which Lenya has, has nothing to do with Java
and I think this is a very bad excuse of yourself to get people into
starting something from scratch.
The main reasons I have started Yanel and use it today successfully (and
not using Lenya anymore) are
- backwards compatibility/upgradeability
- scalability/performance
I have tried to convince this community many times re these core
principles, and some people nodded friendly, but didn't take it
seriously, so I gave up after many, many discussions
With Yanel we do not need releases anymore (except from a marketing
point of view), but can continuously upgrade at any time and it handles
arbitrary amount of content without a problem
Yanel is not perfect and definitely needs some polishing, but since
using it I sleep very well :-), but it makes me sad, that I didn't manage to
pull this off within this community
And yes, Yanel is still Java (and also XML/XSLT) based and I still think
Java is a great language
So, please do not blame Java or its prospects, but start fixing the real
issues.
Cheers
Michael
>
> BTW, recently I did a project using .Net, and I was very positively
> suprised and think it would be a viable alternative. We could finally
> get rid of those endorsed libraries issues and of all our legacy code.
>
> Maybe there are other platforms worth considering? E.g. Ruby on Rails?
>
> [1] http://www.jroller.com/scolebourne/entry/no_more_java_7
>
> WDYT? Any comments are greatly appreciated!
>
> -- Andreas
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Vik Tara <vi...@propco.co.uk>.
> the future of Java is very uncertain
Not sure it's time to jump ship though.
I think there are other players in the Java world who are likely to have
an impact on what is going on - those people with coloured hats for one :)
Also, there is OpenJDK - btw is anyone running Lenya with it?
Should we focus on compatibility with Java 6 rather than worrying about
where Java 7 will or will not go?
My humble opinion.
Vik
Andreas Hartmann wrote:
> Hi everyone,
>
> you might have noticed (e.g. via the blog post [1] which gained a lot of
> publicity) that the future of Java is very uncertain. Maybe the next
> version won't be an open standard anymore.
>
> I think we should seriously consider migrating to another platform. I'm
> sure there must be good reasons that most CMS's are written in PHP
> anyway. There are some quite powerful frameworks (Zend, PEAR) to
> implement complex web applications. Combined with a mature JavaScript
> library like Dojo or YUI we could create a productive system in an
> acceptable timeframe. I think moving to PHP would also help to increase
> the potential user base.
>
> BTW, recently I did a project using .Net, and I was very positively
> suprised and think it would be a viable alternative. We could finally
> get rid of those endorsed libraries issues and of all our legacy code.
>
> Maybe there are other platforms worth considering? E.g. Ruby on Rails?
>
> [1] http://www.jroller.com/scolebourne/entry/no_more_java_7
>
> WDYT? Any comments are greatly appreciated!
>
> -- Andreas
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2009-04-01 at 10:48 -0600, Antonio Gallardo wrote:
> Hi Andreas,
>
> Perhaps we should consider integrating some artificial intelligence to
> lenya. It may be very helpful for some user tasks as autobuilding html
> pages and as a enhanced search engine. I propose we integrate Google
> CADIE[1] into lenya and get rid of the obsolete Apache Lucene.
>
> WDYT?
>
wtf?
¿Obsolete Lucene?, well people are using Solr more and more. It is VERY
easy to integrate a standalone solr server into lenya if we are not
happy with plain lucene.
Why do you think we need to change the search?
For the AI we can use Apache Droids ;)
salu2
> Best Regards,
>
> Antonio Gallardo.
>
> [1] http://www.google.com/intl/en_us/landing/cadie/
Cannot access the page: "We apologize for the recent disruption(s) to
our service(s)."
>
> Andreas Hartmann escribió:
> > Hi everyone,
> >
> > you might have noticed (e.g. via the blog post [1] which gained a lot
> > of publicity) that the future of Java is very uncertain. Maybe the
> > next version won't be an open standard anymore.
> >
> > I think we should seriously consider migrating to another platform.
> > I'm sure there must be good reasons that most CMS's are written in PHP
> > anyway. There are some quite powerful frameworks (Zend, PEAR) to
> > implement complex web applications. Combined with a mature JavaScript
> > library like Dojo or YUI we could create a productive system in an
> > acceptable timeframe. I think moving to PHP would also help to
> > increase the potential user base.
> >
> > BTW, recently I did a project using .Net, and I was very positively
> > suprised and think it would be a viable alternative. We could finally
> > get rid of those endorsed libraries issues and of all our legacy code.
> >
> > Maybe there are other platforms worth considering? E.g. Ruby on Rails?
> >
> > [1] http://www.jroller.com/scolebourne/entry/no_more_java_7
> >
> > WDYT? Any comments are greatly appreciated!
> >
> > -- Andreas
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
--
Thorsten Scherler <thorsten.at.apache.org>
Open Source Java <consulting, training and solutions>
Sociedad Andaluza para el Desarrollo de la Sociedad
de la Información, S.A.U. (SADESI)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Andreas Hartmann <an...@apache.org>.
Hi Antonio,
Antonio Gallardo schrieb:
> Perhaps we should consider integrating some artificial intelligence to
> lenya. It may be very helpful for some user tasks as autobuilding html
> pages and as a enhanced search engine. I propose we integrate Google
> CADIE[1] into lenya and get rid of the obsolete Apache Lucene.
I think this sounds very promising! Speaking of CADIE, maybe we can ask
infrastructure to install Autopilot [1] for our users list? This would
save us a lot of work.
[1] http://mail.google.com/mail/help/autopilot/index.html
-- Andreas
>
> WDYT?
>
> Best Regards,
>
> Antonio Gallardo.
>
> [1] http://www.google.com/intl/en_us/landing/cadie/
>
> Andreas Hartmann escribió:
>> Hi everyone,
>>
>> you might have noticed (e.g. via the blog post [1] which gained a lot
>> of publicity) that the future of Java is very uncertain. Maybe the
>> next version won't be an open standard anymore.
>>
>> I think we should seriously consider migrating to another platform.
>> I'm sure there must be good reasons that most CMS's are written in PHP
>> anyway. There are some quite powerful frameworks (Zend, PEAR) to
>> implement complex web applications. Combined with a mature JavaScript
>> library like Dojo or YUI we could create a productive system in an
>> acceptable timeframe. I think moving to PHP would also help to
>> increase the potential user base.
>>
>> BTW, recently I did a project using .Net, and I was very positively
>> suprised and think it would be a viable alternative. We could finally
>> get rid of those endorsed libraries issues and of all our legacy code.
>>
>> Maybe there are other platforms worth considering? E.g. Ruby on Rails?
>>
>> [1] http://www.jroller.com/scolebourne/entry/no_more_java_7
>>
>> WDYT? Any comments are greatly appreciated!
>>
>> -- Andreas
>>
>>
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Andreas,
Perhaps we should consider integrating some artificial intelligence to
lenya. It may be very helpful for some user tasks as autobuilding html
pages and as a enhanced search engine. I propose we integrate Google
CADIE[1] into lenya and get rid of the obsolete Apache Lucene.
WDYT?
Best Regards,
Antonio Gallardo.
[1] http://www.google.com/intl/en_us/landing/cadie/
Andreas Hartmann escribió:
> Hi everyone,
>
> you might have noticed (e.g. via the blog post [1] which gained a lot
> of publicity) that the future of Java is very uncertain. Maybe the
> next version won't be an open standard anymore.
>
> I think we should seriously consider migrating to another platform.
> I'm sure there must be good reasons that most CMS's are written in PHP
> anyway. There are some quite powerful frameworks (Zend, PEAR) to
> implement complex web applications. Combined with a mature JavaScript
> library like Dojo or YUI we could create a productive system in an
> acceptable timeframe. I think moving to PHP would also help to
> increase the potential user base.
>
> BTW, recently I did a project using .Net, and I was very positively
> suprised and think it would be a viable alternative. We could finally
> get rid of those endorsed libraries issues and of all our legacy code.
>
> Maybe there are other platforms worth considering? E.g. Ruby on Rails?
>
> [1] http://www.jroller.com/scolebourne/entry/no_more_java_7
>
> WDYT? Any comments are greatly appreciated!
>
> -- Andreas
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2009-04-01 at 18:31 +0200, Rudolf Korhummel wrote:
> Hi Andreas,
>
> Please have a look at this very interesting programming language: http://en.wikipedia.org/wiki/Brainfuck
> .
> Even very minimalistic devices are supported !
>
> ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++
> ++++++++++++.>.+++.------.--------.>+.>.
lol
fun with programming.
salu2
>
> Rudolf
>
>
> > Richard Frovarp schrieb:
> >> Andreas Hartmann wrote:
> >>> I think we should seriously consider migrating to another
> >>> platform. I'm sure there must be good reasons that most CMS's are
> >>> written in PHP anyway. There are some quite powerful frameworks
> >>> (Zend, PEAR) to implement complex web applications. Combined with
> >>> a mature JavaScript library like Dojo or YUI we could create a
> >>> productive system in an acceptable timeframe. I think moving to
> >>> PHP would also help to increase the potential user base.
> >>>
> >>> BTW, recently I did a project using .Net, and I was very
> >>> positively suprised and think it would be a viable alternative. We
> >>> could finally get rid of those endorsed libraries issues and of
> >>> all our legacy code.
> >>>
> >>> Maybe there are other platforms worth considering? E.g. Ruby on
> >>> Rails?
> >>>
> >> I think we're missing the bigger picture here. Servers are coming
> >> with more sockets and more cores. It's now about concurrency, not
> >> how fast an individual thread runs. It is way too tough to do this
> >> in an imperative language. For this reason we should switch to a
> >> functional programming language.
> >
> > Very good point.
> >
> >> At the top of my list would be LISP. If something as powerful as
> >> Emacs can be written in LISP, I think it would serve us well. In
> >> fact, if you issue a C-x M-c M-cms, it will generate the skeleton
> >> of a CMS in LISP for you. If you tack on a 1, that will get you the
> >> Clojure derivative, which may be a little more modern, and get us
> >> away from all of the parentheses.
> >
> > Thanks for those pointers, I'll do some prototyping asap!
> >
> >> I think the strongest option would be to write it all in XSLT.
> >> Think about it, it's a Turing complete functional language. We get
> >> concurrency and the ability to run on any platform with an XSLT
> >> engine! It could then run under Java, .Net, Ruby, Python, or PHP.
> >> Sadly, I do not know if there is an XSLT engine for PL/1.
> >
> > I totally agree, XSLT would be a very good choice. Since we already
> > use XSLT for the presentation layer, using it for the business logic
> > as well would tremendously reduce the learning curve. Recursive
> > document() function calls will be a great replacement for Cocoon's
> > XML pipelines.
> >
> > Remember the discussion whether to organize the codebase according
> > to file types or according to functional modules? When we migrate
> > everything to XSLT, we could just put all code files in the
> > $LENYA_HOME/xslt folder and have a very clean and easy to understand
> > codebase.
> >
>
> > Thanks for your valuable input!
> >
> > -- Andreas
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
--
Thorsten Scherler <thorsten.at.apache.org>
Open Source Java <consulting, training and solutions>
Sociedad Andaluza para el Desarrollo de la Sociedad
de la Información, S.A.U. (SADESI)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Jürgen Ragaller <ra...@apache.org>.
Hi there
> ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+
> ++++++++++++++.>.+++.------.--------.>+.>.
That's a great start, Rudolf - clean and and easy to grasp concept.
A jump start to the post java age!
Thanks a lot.
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Antonio Gallardo <ag...@agssa.net>.
Andreas,
Instead of cocoon, we should use SQL On Rails [1] to help manage our
content repository.
Best Regards,
Antonio Gallardo.
[1] http://www2.sqlonrails.org/
Andreas Hartmann escribió:
> Hi Rudolf,
>
> Rudolf Korhummel schrieb:
>> Please have a look at this very interesting programming language:
>> http://en.wikipedia.org/wiki/Brainfuck.
>> Even very minimalistic devices are supported !
>>
>> ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
>>
>
> thanks for the pointer! I guess this is the first language where SVN
> conflicts will result in some valuable (or at least interesting)
> modifications to the code.
>
> Here's another one to consider: http://compsoc.dur.ac.uk/whitespace/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Andreas Hartmann <an...@apache.org>.
Hi Rudolf,
Rudolf Korhummel schrieb:
> Please have a look at this very interesting programming language:
> http://en.wikipedia.org/wiki/Brainfuck.
> Even very minimalistic devices are supported !
>
> ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
thanks for the pointer! I guess this is the first language where SVN
conflicts will result in some valuable (or at least interesting)
modifications to the code.
Here's another one to consider: http://compsoc.dur.ac.uk/whitespace/
-- Andreas
>
>
> Rudolf
>
>
>> Richard Frovarp schrieb:
>>> Andreas Hartmann wrote:
>>>> I think we should seriously consider migrating to another platform.
>>>> I'm sure there must be good reasons that most CMS's are written in
>>>> PHP anyway. There are some quite powerful frameworks (Zend, PEAR) to
>>>> implement complex web applications. Combined with a mature
>>>> JavaScript library like Dojo or YUI we could create a productive
>>>> system in an acceptable timeframe. I think moving to PHP would also
>>>> help to increase the potential user base.
>>>>
>>>> BTW, recently I did a project using .Net, and I was very positively
>>>> suprised and think it would be a viable alternative. We could
>>>> finally get rid of those endorsed libraries issues and of all our
>>>> legacy code.
>>>>
>>>> Maybe there are other platforms worth considering? E.g. Ruby on Rails?
>>>>
>>> I think we're missing the bigger picture here. Servers are coming
>>> with more sockets and more cores. It's now about concurrency, not how
>>> fast an individual thread runs. It is way too tough to do this in an
>>> imperative language. For this reason we should switch to a functional
>>> programming language.
>>
>> Very good point.
>>
>>> At the top of my list would be LISP. If something as powerful as
>>> Emacs can be written in LISP, I think it would serve us well. In
>>> fact, if you issue a C-x M-c M-cms, it will generate the skeleton of
>>> a CMS in LISP for you. If you tack on a 1, that will get you the
>>> Clojure derivative, which may be a little more modern, and get us
>>> away from all of the parentheses.
>>
>> Thanks for those pointers, I'll do some prototyping asap!
>>
>>> I think the strongest option would be to write it all in XSLT. Think
>>> about it, it's a Turing complete functional language. We get
>>> concurrency and the ability to run on any platform with an XSLT
>>> engine! It could then run under Java, .Net, Ruby, Python, or PHP.
>>> Sadly, I do not know if there is an XSLT engine for PL/1.
>>
>> I totally agree, XSLT would be a very good choice. Since we already
>> use XSLT for the presentation layer, using it for the business logic
>> as well would tremendously reduce the learning curve. Recursive
>> document() function calls will be a great replacement for Cocoon's XML
>> pipelines.
>>
>> Remember the discussion whether to organize the codebase according to
>> file types or according to functional modules? When we migrate
>> everything to XSLT, we could just put all code files in the
>> $LENYA_HOME/xslt folder and have a very clean and easy to understand
>> codebase.
>>
>
>> Thanks for your valuable input!
>>
>> -- Andreas
>>
>>
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Rudolf Korhummel <ru...@korhummel.de>.
Hi Andreas,
Please have a look at this very interesting programming language: http://en.wikipedia.org/wiki/Brainfuck
.
Even very minimalistic devices are supported !
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++
++++++++++++.>.+++.------.--------.>+.>.
Rudolf
> Richard Frovarp schrieb:
>> Andreas Hartmann wrote:
>>> I think we should seriously consider migrating to another
>>> platform. I'm sure there must be good reasons that most CMS's are
>>> written in PHP anyway. There are some quite powerful frameworks
>>> (Zend, PEAR) to implement complex web applications. Combined with
>>> a mature JavaScript library like Dojo or YUI we could create a
>>> productive system in an acceptable timeframe. I think moving to
>>> PHP would also help to increase the potential user base.
>>>
>>> BTW, recently I did a project using .Net, and I was very
>>> positively suprised and think it would be a viable alternative. We
>>> could finally get rid of those endorsed libraries issues and of
>>> all our legacy code.
>>>
>>> Maybe there are other platforms worth considering? E.g. Ruby on
>>> Rails?
>>>
>> I think we're missing the bigger picture here. Servers are coming
>> with more sockets and more cores. It's now about concurrency, not
>> how fast an individual thread runs. It is way too tough to do this
>> in an imperative language. For this reason we should switch to a
>> functional programming language.
>
> Very good point.
>
>> At the top of my list would be LISP. If something as powerful as
>> Emacs can be written in LISP, I think it would serve us well. In
>> fact, if you issue a C-x M-c M-cms, it will generate the skeleton
>> of a CMS in LISP for you. If you tack on a 1, that will get you the
>> Clojure derivative, which may be a little more modern, and get us
>> away from all of the parentheses.
>
> Thanks for those pointers, I'll do some prototyping asap!
>
>> I think the strongest option would be to write it all in XSLT.
>> Think about it, it's a Turing complete functional language. We get
>> concurrency and the ability to run on any platform with an XSLT
>> engine! It could then run under Java, .Net, Ruby, Python, or PHP.
>> Sadly, I do not know if there is an XSLT engine for PL/1.
>
> I totally agree, XSLT would be a very good choice. Since we already
> use XSLT for the presentation layer, using it for the business logic
> as well would tremendously reduce the learning curve. Recursive
> document() function calls will be a great replacement for Cocoon's
> XML pipelines.
>
> Remember the discussion whether to organize the codebase according
> to file types or according to functional modules? When we migrate
> everything to XSLT, we could just put all code files in the
> $LENYA_HOME/xslt folder and have a very clean and easy to understand
> codebase.
>
> Thanks for your valuable input!
>
> -- Andreas
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Andreas Hartmann <an...@apache.org>.
Richard Frovarp schrieb:
> Andreas Hartmann wrote:
>> I think we should seriously consider migrating to another platform.
>> I'm sure there must be good reasons that most CMS's are written in PHP
>> anyway. There are some quite powerful frameworks (Zend, PEAR) to
>> implement complex web applications. Combined with a mature JavaScript
>> library like Dojo or YUI we could create a productive system in an
>> acceptable timeframe. I think moving to PHP would also help to
>> increase the potential user base.
>>
>> BTW, recently I did a project using .Net, and I was very positively
>> suprised and think it would be a viable alternative. We could finally
>> get rid of those endorsed libraries issues and of all our legacy code.
>>
>> Maybe there are other platforms worth considering? E.g. Ruby on Rails?
>>
>
> I think we're missing the bigger picture here. Servers are coming with
> more sockets and more cores. It's now about concurrency, not how fast an
> individual thread runs. It is way too tough to do this in an imperative
> language. For this reason we should switch to a functional programming
> language.
Very good point.
> At the top of my list would be LISP. If something as powerful as Emacs
> can be written in LISP, I think it would serve us well. In fact, if you
> issue a C-x M-c M-cms, it will generate the skeleton of a CMS in LISP
> for you. If you tack on a 1, that will get you the Clojure derivative,
> which may be a little more modern, and get us away from all of the
> parentheses.
Thanks for those pointers, I'll do some prototyping asap!
> I think the strongest option would be to write it all in XSLT. Think
> about it, it's a Turing complete functional language. We get concurrency
> and the ability to run on any platform with an XSLT engine! It could
> then run under Java, .Net, Ruby, Python, or PHP. Sadly, I do not know if
> there is an XSLT engine for PL/1.
I totally agree, XSLT would be a very good choice. Since we already use
XSLT for the presentation layer, using it for the business logic as well
would tremendously reduce the learning curve. Recursive document()
function calls will be a great replacement for Cocoon's XML pipelines.
Remember the discussion whether to organize the codebase according to
file types or according to functional modules? When we migrate
everything to XSLT, we could just put all code files in the
$LENYA_HOME/xslt folder and have a very clean and easy to understand
codebase.
Thanks for your valuable input!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Richard Frovarp <Ri...@ndsu.edu>.
Andreas Hartmann wrote:
> I think we should seriously consider migrating to another platform.
> I'm sure there must be good reasons that most CMS's are written in PHP
> anyway. There are some quite powerful frameworks (Zend, PEAR) to
> implement complex web applications. Combined with a mature JavaScript
> library like Dojo or YUI we could create a productive system in an
> acceptable timeframe. I think moving to PHP would also help to
> increase the potential user base.
>
> BTW, recently I did a project using .Net, and I was very positively
> suprised and think it would be a viable alternative. We could finally
> get rid of those endorsed libraries issues and of all our legacy code.
>
> Maybe there are other platforms worth considering? E.g. Ruby on Rails?
>
I think we're missing the bigger picture here. Servers are coming with
more sockets and more cores. It's now about concurrency, not how fast an
individual thread runs. It is way too tough to do this in an imperative
language. For this reason we should switch to a functional programming
language.
At the top of my list would be LISP. If something as powerful as Emacs
can be written in LISP, I think it would serve us well. In fact, if you
issue a C-x M-c M-cms, it will generate the skeleton of a CMS in LISP
for you. If you tack on a 1, that will get you the Clojure derivative,
which may be a little more modern, and get us away from all of the
parentheses.
I think the strongest option would be to write it all in XSLT. Think
about it, it's a Turing complete functional language. We get concurrency
and the ability to run on any platform with an XSLT engine! It could
then run under Java, .Net, Ruby, Python, or PHP. Sadly, I do not know if
there is an XSLT engine for PL/1.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Richard Frovarp <rf...@apache.org>.
Thomas Comiotto wrote:
> Hi Andreas
>
>>
>>
>> Maybe there are other platforms worth considering? E.g. Ruby on Rails?
>>
>> [1] http://www.jroller.com/scolebourne/entry/no_more_java_7
>>
>> WDYT? Any comments are greatly appreciated!
>>
>
> I'd wait and see what other Apache projects that use Java do.
>
> Bests
> Thomas
>
>
I don't know of Michael or Doug went to it or not, but there was a talk
at ApacheCon 2005 in San Diego about how Cobol was catching on again.
The SpamAssassin people weren't impressed (but who listens to Perl devs
anyway?), and it has been 3 years for it to gain momentum. Maybe we
should look at that?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Thomas Comiotto <th...@id.uzh.ch>.
Hi Andreas
>
>
> Maybe there are other platforms worth considering? E.g. Ruby on Rails?
>
> [1] http://www.jroller.com/scolebourne/entry/no_more_java_7
>
> WDYT? Any comments are greatly appreciated!
>
I'd wait and see what other Apache projects that use Java do.
Bests
Thomas
Re: No more Java 7: Move to PHP, .Net or something else?
Posted by Anish <an...@techblue.co.uk>.
> Hi everyone,
>
> you might have noticed (e.g. via the blog post [1] which gained a lot
> of publicity) that the future of Java is very uncertain. Maybe the
> next version won't be an open standard anymore.
Hi All
I agree there are a lot of technologies like PHP, .NET, cgi,
python...... etc. which could work for us.
But I think we should consider a technology which could compete JAVA. As
in my view PHP or Microsoft Technologies like ASP/ASP.NET are not worth
considering.
I think we should consider something robust like Ruby on Rails, Python,
Perl etc...
Please comment...
Andreas Hartmann wrote:
> Hi everyone,
>
> you might have noticed (e.g. via the blog post [1] which gained a lot
> of publicity) that the future of Java is very uncertain. Maybe the
> next version won't be an open standard anymore.
>
> I think we should seriously consider migrating to another platform.
> I'm sure there must be good reasons that most CMS's are written in PHP
> anyway. There are some quite powerful frameworks (Zend, PEAR) to
> implement complex web applications. Combined with a mature JavaScript
> library like Dojo or YUI we could create a productive system in an
> acceptable timeframe. I think moving to PHP would also help to
> increase the potential user base.
>
> BTW, recently I did a project using .Net, and I was very positively
> suprised and think it would be a viable alternative. We could finally
> get rid of those endorsed libraries issues and of all our legacy code.
>
> Maybe there are other platforms worth considering? E.g. Ruby on Rails?
>
> [1] http://www.jroller.com/scolebourne/entry/no_more_java_7
>
> WDYT? Any comments are greatly appreciated!
>
> -- Andreas
>
>
--
Anish Sneh
Software Engineer
Techblue Softwares Pvt. Ltd.
www.technologyblueprint.co.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org