Skip to main content

Perfect Example of Strategic Plan

14 replies [Last post]
vladperl
Offline
Joined: 2004-08-11

I believe it's time to design the future strategy for JSF.
The corresponding plan have to be written in honest and clear manner to provide a real benefit.
Suddenly I have found the perfect example of this kind of plan.
The plan is written by person with weird name "JESSE COSTELLO-GOOD".
I suppose that he could take a new name for himself such as "JESSE COSTELLO-GOOD-STRATEGIC-PLAN" :)

Please read the following plan:
http://www.generalinterface.org/docs/display/OS/GI+4.0+Planning

The plan is interesting because it show the way of thinking when many strategic moves have to be activated.
He is ready to redesign completely many parts of existing architecture in case to succeed.
It looks like the JSF expert team should take the same approach.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vladperl
Offline
Joined: 2004-08-11

Hi Ed,
>want *you*, Vlad, to throw some ideas up there
>http://wiki.java.net/bin/view/Projects/JsfCommunityRoadMap

I have tried to use the wiki page you setup recently but preview option doesn't work.

I'm constantly getting the following message:

"TWiki Installation Error
Template "oopsinvalidtoken" not found.

Check the configuration settings for {TemplateDir} and {TemplatePath}. "

I'm thinking about creating on temporal basis Wordpress blog to start the discussion.
I could put the blog link to the wiki page as reference point.
In my opinion wordpress kind of blog is more powerful tool to organize this type of discussion.
Anyway if the issue with wiki page will be fixed I will use it at least during the final stage.

Best regards,
Vladimir

Ed Burns

>>>>> On Tue, 16 Mar 2010 21:00:32 -0700 (PDT), webtier@javadesktop.org said:

VP> Hi Ed,
>> want *you*, Vlad, to throw some ideas up there
>> http://wiki.java.net/bin/view/Projects/JsfCommunityRoadMap

VP> I have tried to use the wiki page you setup recently but preview option doesn't work.

VP> I'm constantly getting the following message:

VP> "TWiki Installation Error
VP> Template "oopsinvalidtoken" not found.

Ahh, the java.net wiki.

Look, let's use the JCP wiki. Dan Allen already started a page for
this. Get yourself a jcp.org id and add your content in here:

http://wiki.jcp.org/wiki/index.php?page=JSF+Proposed+Features

Please don't do it on your own page, it will get more confusing and have
a higher chance of getting lost.

Ed

--
| edward.burns... | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

vladperl
Offline
Joined: 2004-08-11

>Look, let's use the JCP wiki. Dan Allen already started a page for
>this. Get yourself a jcp.org id and add your content in here:

Thank you! I'm going to do it.

>Please don't do it on your own page, it will get more confusing and have
>a higher chance of getting lost.

I understand your point and will follow your advice.

vladperl
Offline
Joined: 2004-08-11

T>So unless or until I am involved in a more typical JSF use case environment, I am not
T>sure I am the right target developer for JSF overall.

Just because of this you could provide fresh insight on this matter.
I already have about dozen ideas that seems is a good fit to make them as strategic goals for JSF.
But some of them are too radical to present them without some kind of preparing.
Simply put I just don't like the scenario when the ideas will be ignored or easily dismiss.
I figure out that you definitely took a look inside of JSF source code and your experience with jQuery should be helpful also.

Please read the following plan to see what I mean when talking about preparation:
1) Provide conclusion if the ideas are making sense and workable in current situation.
2) Workout the ideas on detail level
3) Help to present the ideas in clear and convincing manner
4) Create working prototypes as extra supporting points
5) Create coalition of developers who are interesting to put them in production

If you really are interested to discuss this kind of stuff please contact me by email:
vladperlAThotmail.com

By the way I'm wondering if "tacitust" word has some meaning :)

Best regards,
Vladimir

Ed Burns

>>>>> On Sat, 13 Mar 2010 18:34:58 -0800 (PST), webtier@javadesktop.org said:

VP> Please read the following plan to see what I mean when talking about
VP> preparation:

VP> 1) Provide conclusion if the ideas are making sense and workable in
VP> current situation.

VP> 2) Workout the ideas on detail level

VP> 3) Help to present the ideas in clear and convincing manner

VP> 4) Create working prototypes as extra supporting points

VP> 5) Create coalition of developers who are interesting to put them in
VP> production

This is a great recommendation. Any successes we have in JSF 2.0 come,
at least in part, from the JSF Expert Group harvesting of ideas that
have gone through a similar process *and* have proven themselves worthy
in the community. I strongly prefer not to add stuff to the JSF
standard until the "proven themselves worthy in the community" part has
happened.

Ed

--
| edward.burns... | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

vladperl
Offline
Joined: 2004-08-11

>This is a great recommendation. Any successes we have in JSF 2.0 come,
>at least in part, from the JSF Expert Group harvesting of ideas that
>have gone through a similar process *and* have proven themselves worthy
>in the community. I strongly prefer not to add stuff to the JSF
>standard until the "proven themselves worthy in the community" part has
>happened.

It's reasonable point of view.
If the JSF community will refuse actively participate in discussion regarding strategic goals for JSF than it will be completely their loss.
I have started to scan forum threads in case to find new ideas or to polish existing.
Now, I'm ready to start the whole thing.
Thank you again for your support.

Ed Burns

>>>>> On Sat, 06 Mar 2010 20:31:38 -0800 (PST), webtier@javadesktop.org said:

VP> I believe it's time to design the future strategy for JSF. The
VP> corresponding plan have to be written in honest and clear manner to
VP> provide a real benefit. Suddenly I have found the perfect example
VP> of this kind of plan. The plan is written by person with weird name
VP> "JESSE COSTELLO-GOOD". I suppose that he could take a new name for
VP> himself such as "JESSE COSTELLO-GOOD-STRATEGIC-PLAN" :)

Yes, this seems like a decent plan. Believe it or not, we did
exactly this kind of thing when we started development of JSF 2.0 in
earnest, but we did it on a wiki [1] and solicited community input.
Furthermore, we continued to fold in communyity input as we went. [2]

VP> Please read the following plan:
VP> http://www.generalinterface.org/docs/display/OS/GI+4.0+Planning

VP> The plan is interesting because it show the way of thinking when
VP> many strategic moves have to be activated. He is ready to redesign
VP> completely many parts of existing architecture in case to succeed.
VP> It looks like the JSF expert team should take the same approach.

So, in essence, you are really saying that it looks like the JSF expert
team should take the same approach they did with JSF 2.0.

>>>>> On Sun, 07 Mar 2010 16:10:18 -0800 (PST), webtier@javadesktop.org said:

T> I've only recently come back to JSF, so I don't know, but do you
T> think that the existing JSF requirements and design processes are
T> lacking in some way?

Thank you for pointing out this perspective.

>>>>> On Mon, 08 Mar 2010 10:29:20 -0800 (PST), webtier@javadesktop.org said:

T> can't afford to do a complete redesign that will break backwards
T> compatibility all over the place.

VP> JSF 2.0 introduced several radical changes. Good examples of such
VP> changes are composition components, partial rendering and supporting
VP> parameters with EL.

We worked very hard to introduce those changes in a way that users could
easily adopt them without breaking backwards compatibility.

T> but if you start to make fundamental changes to the architecture that
T> are exposed to external interfaces then you're usually better off
T> starting (yet another) new framework entirely.

VP> I believe that breaking backward compatibility more affordable path
VP> than switching to a new framework :)

Vlad, I appreciate and respect your enthusiasm. I think what you're
looking for is a community roadmap for JSF. I've started the page, I
want *you*, Vlad, to throw some ideas up there
.

T> Skimming the GI 4.0 document, I don't really see anything
T> extraordinary about it. It seems to be a mishmash of ideas from the
T> main developer mixed in with a discussion of some of the requirements
T> and requests that users have made.

VP> I understand your point. You are right it's not definitive strategy
VP> document. But this kind of document is the good start to make such
VP> plan. I never see that JSF team layout in such manner the issues
VP> related to the architecture of JSF. That is the reason why it looks
VP> so extraordinary to me :)

Just because you haven't seen it, doesn't mean it does not exist.

VP> Here is the small illustration of my point:

T> GI is too coupled to XML, it has no XML-JSON equivalence, it has no
T> source- and format-agnostic data API, and its data controls cannot be
T> populated with domain objects

VP> JSF has no support for JSON, there is no language-agnostic data API,
VP> DataTable is not very flexible and we can't use Dojo Datagrid
VP> directly.

Why should *JSF* have support for JSON? Clearly JSF isn't the only part
of Java that would benefit from JSON (as shown by the existence of
several Java JSON solutions). Doesn't that seem like something the core
Java platform should have? Your suggestion lets me illustrate one
aspect of specification development that is not obvious: placing things
in their proper context. Sure, it's easy to say: "JSF should have this,
and JSF should have that" but JSF is a part of the JavaEE platform. We
can't just grab features left and right, as non-platform frameworks *can
and should* do.

T> GI includes synchronous APIs for server communication even though
T> such calls >> always cause performance problems

VP> JSF life cycle defined around synchronous server communication so we
VP> have the same problems

Yes, leveraging HTML5 WebSocket is important.

T> Formal interface is too heavyweight for many cases where you want to
T> declare a simple contract.

VP> JSF is too component oriented and every java based JSF component
VP> indeed is very heavyweight considering how many methods and
VP> properties it includes. If you saw DataTable component code you
VP> will know what I mean.

I love this. Some say JSF is not component oriented enough. Now you're
saying it's *too* component oriented.

T> I've only recently come back to JSF, so I don't know, but do you
T> think that the existing JSF requirements and design processes are
T> lacking in some way?

VP> Yes, I do think we have some problems in this respect. JSP as
VP> rendering engine was outdated many years ago and only recently they
VP> switched it to facelets.

Only recently? Users could switch to facelets as soon as facelets
existed, which was in 2005. You are confusing the date of specification
with the date of availability. As long as I'm spec lead, the date of
availability will always predate the date of specification.

VP> Supporting parameters with EL was included
VP> also just a few months ago.

Doch, JBoss EL (written by Jacob Hookom at the request of Gavin King)
has had this feature since Seam came out.

VP> You will no see link from JSF project
VP> page to place where you can make suggestions to improve JSF
VP> specification.

I've been soliciting such comments via my blog entries, occasionally
pointing to wikis for more detailed discussion, for years.

VP> JSF team never organize real discussion regarding
VP> strategy of JSF.

Become an observer on JSR-314-OPEN. You'll see the
discussions.

This is from MARCH 2009! How can you say NEVER?

VP> The plan is going to be very radical by nature but I will try to
VP> keep constructive tone with it. Hope you personally will provide
VP> your insight on future of JSF.

As I said, I welcome and encourage your participation. Put it up on the
wiki page I started.

[1] http://wiki.java.net/bin/view/Projects/Jsf2Requirements
[2] http://wiki.java.net/bin/view/Projects/Jsf2RequirementsScratchpad

--
| edward.burns... | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

vladperl
Offline
Joined: 2004-08-11

Ed,
I appreciate your detail response.
For some reason several links you have provided appears in the forum as empty.
But I have all of them in my corresponding email so I will put them in response.

>Yes, this seems like a decent plan. Believe it or not, we did
>exactly this kind of thing when we started development of JSF 2.0 in
>earnest, but we did it on a wiki [1] and solicited community input.
>Furthermore, we continued to fold in communyity input as we went. [2]

You are right the JSF 2.0 plan was indeed very similar and addresses wide circle of issues.
But the plan was in use a couple years ago. Now we need to have a new plan to see our perspective. This is the reason I have started the thread :)

>We worked very hard to introduce those changes in a way that users could
>easily adopt them without breaking backwards compatibility.
I can confirm it. At least for us it was so easy to switch to JSF 2.0 that I wouldn't call it migration :)

>Vlad, I appreciate and respect your enthusiasm. I think what you're
>looking for is a community roadmap for JSF. I've started the page, I
>want *you*, Vlad, to throw some ideas up there
>http://wiki.java.net/bin/view/Projects/JsfCommunityRoadMap
Thank you for support! I definitely will put there a bunch of ideas.
If ten percents of the ideas will be implemented I will be happy in this respect.
It would be helpful to know what time period we have to defined, polish and post ideas to the road map.

>Just because you haven't seen it, doesn't mean it does not exist.
Now I remember the plan. I have seen it, but it was a long time ago and I forgot ;)

>Why should *JSF* have support for JSON? Clearly JSF isn't the only part
>of Java that would benefit from JSON (as shown by the existence of
>several Java JSON solutions). Doesn't that seem like something the core
>Java platform should have? Your suggestion lets me illustrate one
>aspect of specification development that is not obvious: placing things
>in their proper context. Sure, it's easy to say: "JSF should have this,
>and JSF should have that" but JSF is a part of the JavaEE platform. We
>can't just grab features left and right, as non-platform frameworks *can
>and should* do.
Here are my reasons:
1) The biggest area of JSON usage is web framework(JSF) comparing to other parts of JavaEE.
2) JSON could improve such processes as HTML Rendering, data exchange server with client, implementing data model, more web oriented event model and so on.
3) Including "native" support of JSON eventually will bring positive in many cases radical changes to the architecture of JSF framework.
4) Including additional part to existing specification easier to implement than creating completely new part of JavaEE.

No doubt that after concept of using JSON will take solid form it should be moved to separate specification.

>Yes, leveraging HTML5 WebSocket is important.
If I understand correctly implementing this thing will bring fairly radical change to JSF.

>I love this. Some say JSF is not component oriented enough. Now you're
>saying it's *too* component oriented.
One of the reason I have said so is that it's a good idea to completely eliminate java based rendering code at all from the framework :)
Composition component is a good start to this direction.

>Only recently? Users could switch to facelets as soon as facelets
>existed, which was in 2005. You are confusing the date of specification
>with the date of availability. As long as I'm spec lead, the date of
>availability will always predate the date of specification.
If you recommended it at this time I would without much thinking switch to facelets.
Please next time use your influence in such situations :)

>Doch, JBoss EL (written by Jacob Hookom at the request of Gavin King)
>has had this feature since Seam came out.
The same here I was waiting for recommendations from JSF team.
Maybe next time I will be less connected to official line.

>I've been soliciting such comments via my blog entries, occasionally
>pointing to wikis for more detailed discussion, for years.
Yes, recently I was trying to find something on your blog and it was a little bit painful to navigate between months of archive.
I understand it's not your fault that creators of blogs system have no idea how to apply scrollbar for navigation between posts.

>Become an observer on JSR-314-OPEN. You'll see the
>discussions.
>http://weblogs.java.net/blog/edburns/archive/2009/03/response_to_a_c.html
I did. Thank you for suggestion.
>This is from MARCH 2009! How can you say NEVER?
A little more advertisement would be helpful.

>As I said, I welcome and encourage your participation. Put it up on the
>wiki page I started.
I will do it. Let's make the JSF a more exciting framework :)

Ed Burns

>>>>> On Tue, 09 Mar 2010 21:22:58 -0800 (PST), webtier@javadesktop.org said:

V> I appreciate your detail response.

And I yours.

[...]

EB> Become an observer on JSR-314-OPEN. You'll see the
EB> discussions.
EB> http://weblogs.java.net/blog/edburns/archive/2009/03/response_to_a_c.html

V> I did. Thank you for suggestion.

EB> This is from MARCH 2009! How can you say NEVER?

V> A little more advertisement would be helpful.

Exactly. I wish we had the resources to do this properly, but as it
stands now, every minute I spend on community building and marketing is
time I can't spend developing the spec and fixing bugs in the
implementation. So far, I've made the trade off to do the minimal
marketing I can to keep things alive while my high value time is spent
on the core technology.

The engineers working on JSF have been requesting to management for
years to fix this problem, but we all live in a market economy. I agree
with and support the investment choices that have been made so far.

You can see that we're even facing cuts in the team as evidenced by the
recent layoffs from the Oracle acquistition of Sun.

The best answer to this is to keep doing what we're doing now: building
and encouraging community. Vlad, for your part, I'd appreciate you
voicing your opinions regarding "more marketing/awereness for existing
community efforts" on the aquarium blog.

http://blogs.sun.com/theaquarium

Ed

--
| edward.burns... | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

vladperl
Offline
Joined: 2004-08-11

>You can see that we're even facing cuts in the team as evidenced by the
>recent layoffs from the Oracle acquistition of Sun.
This is the main reason why I have started talking about JSF market share.
I perfectly understand how hard is to do coding and marketing in the same time.
But marketing situation seems is very unstable the whole industries have started to shrink very fast.
And you know that in many cases only programmer capable to see how some kind of technological advance can change the market situation.
I just suggest to define JSF strategy with market strategy in mind.

>The best answer to this is to keep doing what we're doing now: building
>and encouraging community. Vlad, for your part, I'd appreciate you
>voicing your opinions regarding "more marketing/awereness for existing
>community efforts" on the aquarium blog.

>http://blogs.sun.com/theaquarium

I like this idea. It's quite a popular blog.
Thank you for suggestion!

tacitust
Offline
Joined: 2010-02-24

I don't know anything about GI, but given the small size of its community forum, I think it is pretty safe to assume that it has a very small user base and can do pretty much what it likes from one version to the next if the core group of users agrees to it.

JSF on the other hand has a very large user base with uncounted millions of lines of legacy code over the last decade and can't afford to do a complete redesign that will break backwards compatibility all over the place. Internal refactoring of the code is certainly possible, but if you start to make fundamental changes to the architecture that are exposed to external interfaces then you're usually better off starting (yet another) new framework entirely.

Skimming the GI 4.0 document, I don't really see anything extraordinary about it. It seems to be a mishmash of ideas from the main developer mixed in with a discussion of some of the requirements and requests that users have made. It goes into plenty of detail, that's true, but it reads more like one person's stream of consciousness then a definitive strategy document.

I've only recently come back to JSF, so I don't know, but do you think that the existing JSF requirements and design processes are lacking in some way?

vladperl
Offline
Joined: 2004-08-11

>can't afford to do a complete redesign that will break backwards compatibility all over the place.
JSF 2.0 introduced several radical changes. Good examples of such changes are composition components, partial rendering and supporting parameters with EL.
It was very ease to integrate the new stuff and it provided significant benefits to the whole process of software development.
Yes, sometimes it breaks backward compatibility, but in most cases it takes very little time to work it out.
Of course for component developers it's a bigger issue to deal with breaking backward compatibility.

>but if you start to make fundamental changes to the architecture that are exposed to
>external interfaces then you're usually better off starting (yet another) new framework
>entirely.
I believe that breaking backward compatibility more affordable path than switching to a new framework :)

Do not break backward compatibility too long and market will break it for you :)

Without exception every framework have to be revised radically time from time in case to be in line with a new reality.
Now it's the time to do it because JSF 2 provide solid ground for this move.

>Skimming the GI 4.0 document, I don't really see anything extraordinary about it.
>It seems to be a mishmash of ideas from the main developer mixed in with a discussion
>of some of the requirements and requests that users have made. It goes into plenty of
>detail, that's true, but it reads more like one person's stream of consciousness then a
>definitive strategy document.

I understand your point. You are right it's not definitive strategy document.
But this kind of document is the good start to make such plan.
I never see that JSF team layout in such manner the issues related to the architecture of JSF.
That is the reason why it looks so extraordinary to me :)
Beside it many issues described in the plan relevant in some way to problems that JSF is faced.

Here is the small illustration of my point:
>GI is too coupled to XML, it has no XML-JSON equivalence, it has no source- and
>format-agnostic data API, and its data controls cannot be populated with domain objects
JSF has no support for JSON, there is no language-agnostic data API, DataTable is not very flexible and we can't use Dojo Datagrid directly.
>GI includes synchronous APIs for server communication even though such calls
>always cause performance problems
JSF life cycle defined around synchronous server communication so we have the same problems
>Formal interface is too heavyweight for many cases where you want to declare a simple contract.
JSF is too component oriented and every java based JSF component indeed is very heavyweight considering how many methods and properties it includes.
If you saw DataTable component code you will know what I mean.

>I've only recently come back to JSF, so I don't know, but do you think that the existing
>JSF requirements and design processes are lacking in some way?
Yes, I do think we have some problems in this respect.
JSP as rendering engine was outdated many years ago and only recently they switched it to facelets.
Supporting parameters with EL was included also just a few months ago.
You will no see link from JSF project page to place where you can make suggestions to improve JSF specification.
JSF team never organize real discussion regarding strategy of JSF.
They mostly oriented towards software vendors as opposite to community of JSF users.
Partially I can explain this situation because most of the JSF users never challenge wisdom of the specification.
I know that JSF team have started some activities related to future of JSF as usually in silence mode ;)
So I'm going to present very soon my strategic plan for them to see.
The plan is going to be very radical by nature but I will try to keep constructive tone with it.
Hope you personally will provide your insight on future of JSF.
Of course you can keep silence that is usual practice with JSF users but don't be too
upset if JSF will become irrelevant in some near future :)

tacitust
Offline
Joined: 2010-02-24

Well, I'll be interested to hear what you have to say.

I'm not really in a position to help map out the future of JSF as of yet. As I said, I have only recently come back to it after many years away, and I am not sure exactly how long I will be staying. I am using it with part of a personal project I am working on, but the core piece of the project is based on the client using jQuery, so I doubt I will be delving too deeply into the JSF components any time soon.

I am also leery of the "weight" of JSF, and grappling with the JSF lifecycle certainly takes some getting used to. However, there are always going to be some tradeoffs between usability, ease of development and performance. Given my limited budget and resources, I am probably much more aware of the extra cost in terms of CPU cycles and memory use than the average corporate developer -- they aren't concerned about keeping within the daily free limits of the Google App Engine for example, or perhaps the 512MB memory limit of a $30/month VPS account.

So unless or until I am involved in a more typical JSF use case environment, I am not sure I am the right target developer for JSF overall.

vladperl
Offline
Joined: 2004-08-11

>Well, I'll be interested to hear what you have to say.
Thank you for reply!
JSF lifecycle will be mention in my plan also :)