Hi,
> EB> Hello Volunteers,
> EB> We are just about to start the meeting. The number is
> EB> +1 866 682 4770
> EB> access code 7821409
> EB> security code 2323
> EB> I will record the audio and upload it.
> https://java.net/projects/javaserverfaces-spec-public/downloads/download/JSF_2_3/Early%20Draft%20Review/20140929-servlet4-jsf23-eg-audio.m4a
I just finished the transcript. I'm aware that I probably did not
capture what everyone was saying to the letter, but I did my best. If
there are any glaring mistakes, or if you otherwise have any comments
or things to comment, please let me know.
* Start of transcript *
Ed: I didn't really make an agenda, we only have an hour. I know
everyone's really busy at JavaOne. I'm glad you all came. But I really
wanted to just do this at the kickoff for JSF 2.3 and Servlet 4.0. So
I will start with introductions and then I want to put up the intended
schedule.
Because we don't have a job defined. You know, we move that first, and
then we'll open … I want to take the most advantage of the fact that
we're all in the same room. So I think design discussions or kind of
high level ideas would probably be a good thing to do. And I also
would like to set the tone what I would like to do with this expert
group going forward. I like to keep it very collaborative, very open.
If people want to change the process of how we're doing things I want
you guys to know to please speak up. I'm open to change things. …
Does it make sense, since we have both Servlet and JSF expert group
members here, does it make sense to stand this time focussed on and
kind of issues that are good for bolt steps to deal with like roc
reflection or thing and you have some ideas about direct to DOM and
things? So does that make sense to focus on common issues here?
Sure
All right, I do wanna give people the opportunity to just, if they
have any maintain or… I really like to see DOM and REXX … check in
with the weather.
So let's start with the introduction. My name is Ed Burns and I'm very
pleased to be also helping out with the Servlet in addition to my
usual role as JSF, so we'll go around this way.
Justin: My name is Justin Lee, I'm a former GlassFisher with these
guys. I worked on web sockets; both implementing the protocol and the
spec, with Greg and Colty.
[3:10]
Ed: So you're with Mongo right?
Justin: I'm with Mongo. And we're in the final stages somewhere in the
process of the paperwork for Mongo to join as a corporate entity
Ed: Right, so Mongo will be a formal JCP member?
Justin: Yeah, it's very exciting
Cool!
Ed: Cool, and therefor on the Servlet expert group?
Justin: yeah
Manfred: Are there any other expert groups that mongo will be a part of?
Justin: I don't know. Mongo is a kind of a weird shop. Cause it's
mostly C++ guys. I think there are two of us in the company that know
what the JCP is. Break, before the rule before this conversation
started a few more now. But since we will be corporate members it'll
be interesting to look around and see where we might be able to
contribute.
Greg: … json fabric in IntellJ … this ...
Justin: Yes! We're trying to .. sold.
Greg: … pumping …
Justin: Json schema and invalidation and such could be interesting
places to read about as well, since of the things we're looking at.
Ed: okay...
Neil: I'm Neil Griffin and I'm with Liferay and I'm representing
Liferay on JSF 2.3 and Servlet 4 and MVC and Portlet 3 and -maybe- the
next version of the JSF-Portlet bridge if that happens.
Ed: oh man!
Neil: And I try to get some sleep in my spare time.
Greg: I'm Greg Wilkins. I've been trying to get http servlet for 19
years now. Still haven't got it right, still working on it. So
hopefully, 22nd birthday next year will have it finished. Maybe! I've
been on the Servlet expert group since 2.4 or 2.6, I can't remember.
One of those ones.
Ken: I'm Ken Paulsen. I'm with eBay. And eBay was still stuck on an
older version of JSF, but we're no longer stuck and I'm actually
looking forward to be making JSF 2.3 now.
Ed: And do please speak up for the benefits of those on the phone
Ken: I was a former Oracle employee about 3 or 4 years ago. Now
enjoying eBay equally or as much if not more. And I'm working with
GlassFIsh.
Kito: I'm Kito Mann. I've been an expert group member of JSF for a
long time, I think since 1.2 actually. I've also been a member of the
jsf portlet export group and also CDI but right now the JSF and
Portlet EGs and I do a lot of consulting and training.
Manfred: I'm Manfred Riem I'm the JSF 2.3 co-spec lead together with
Ed and MVC co-spec lead as well.
Werner: I'm Werner Keil. I was in the JSF expert group of 2.2 also a
couple of others especially the Java EE umbrella. I already joined the
CDI 2 expert groups and considering to support EE 8 and MVC and I'm
also in the Portlet 3 expert group so I'm especially looking forward
for things that matter to [konie] and I also try the expert group a
lot. I'm also in the role of expert group, so I try to focus on
external items. But, also a long time member of the EE umbrella I
tried to find similarities, e.g. between @Inject and CDI. For example
from the MVC point of view we have at least one who's spec lead of
both.
Ed: And you also represent the EC, the JCP …
Werner: : I'm the I'm the only individual left in the EC for the time being.
You're the only one who pays attention to the EC
Shing: I'm Shing Wai Chan I've worked on JSR 1964 and then I also work
on server 3.1 and now on Servlet 4.0.
Ed: Okay, so the next item of action is to go through the agenda and
schedule. I'm just going to put that up on the flipboard, but first
pull it up in front of my own eyes, cause I haven't memorized it. So
I'm opening up the slides from the presentation that Shing Wai and I
gave just moments ago, and here's the schedule slide. Can you read
this to me right up there.
First thing. So the EG is Q3. - 2014
Q3
And then we have early draft in Q1 and public review in Q3 and
proposed final draft is Q4. Final release is Q3 2016.
Is that because of the tentative calendar for Java EE 8?
Yes, we might finish before that or we might finish just … you know...
We try to align , […] there could be a lot of time between those two.
Which is nice to have that time we get.
Ed: Couple of different iterations. Between final drafts. Multiple
post final drafts. Between the first and final one. Release
candidates.
Ed: We got a couple of different approaches that we're going to be
doing here. On the JSF side we talk about this in boss tonight. We
really are trying to have 2.3 from Oracle's perspective be all about
polish and making everything fit well together and align with other
specs and just kind of finishing off and really getting it in a good
state. Making it really, really solid. Now we also would like to open
up to the community if they would like to drive some of these issues
that they have, some really cool exciting new ideas, like the one you
shared with me earlier or the one where we are going to be talking
about tonight that Ian out there and Kito had some ideas too, in
partnership with the community, we're going really relying on the
community to design and help and implement and move it forward, cause
we have a lot of different stuff going on at Oracle, and we can't
really commit to too much so as far as features new features goes for
the JSF perspective. On the Servlet perspective what we're trying to
do is just have the HTTP 2 and a few other features exposed.
[11:17]
Greg: Question on that! Why did you decided to go with 4.0 and not
3.2? Since that implies some more changes than.. certainly...
Ed: To me, I think HTTP2 is a big change for the user perspective.
Like c'mon this is the first revision to HTTP that there's been since
1997 or so. That's why I thought it was just right to go for.
Neil: But that's kind of behind the scenes mostly change. Does that
imply like drastic API user interface refactoring?
Shing: no
Neil: But does it preclude it?
Ed: I would say, yes we're not going to really do that.
Kito: I though that when I first heard 4.0 I was like Ohh we can like
take the lid off. We can streamline the API in certain places
[…]
Ed: right
Greg: okay!
Ed: It could have gone either way, I just thought 3.2 was not quite enough
Ed: So, uh, but, does everyone on the JSF side, now that I've, you
know, put that out there, does anyone have any trouble with us taking
that approach? Or is anyone feeling let down by that? Like oh man I
was hoping Oracle would really get onboard and you know commit lots of
resources to be doing a whole new thing, extending the capabilities of
JSF, broadening the scope and all that stuff, cause we're not really
trying to do that.
Neil: I can't say I'm let done by it. But I was hoping to see a couple
of more bigger ticket items., like the thing I was sharing.
Ed: Well, I'm open to it
Neil: The reason why is because my concern is that JSF is old and even
though there's lots and lots of innovation and lots and lots of
reasons to use it, and we have adopted to that technology for mobile
and for push and for all kinds of reasons I take it that it's
important for people to see that there's at least, when it comes to
the level of JSF 2.2 where we have Faces Flows and big ticket items
like that, we'd like to see at least one. And if that calls for
greater participation from the EG to get it done […]
Ed: Yeah it certainly will, and opening up to the idea
[14:16]
Ed: One of the smaller things that we'll be talking about in the
meeting tonight is that we'd like the ability of an AJAX request to
the server that doesn't have a view with it. So, you've got the JSF
lifecycle but you don't have a specific view. What you do have is a
client window, you can do AJAX for that. So that's not at the same
level as the flows.
Kito: I'd expected a lot of those things, which other frameworks
already do on top of JSF, to be doing some of the things that …
Ed: exactly
Manfred: […] I'm so happy to have some of the OmniFaces utility
framework … so to say on board and that they're willing to participate
back with their open source product so that we can actually do that
particular thing and actually get that in the standard instead of
having people to rely on some things outside the standard.
Kito: yeah, great
Ed: Okay, it's good to talk about the scope. So I want to make sure we
establish that. Any other questions about scope issues. Leonardo, can
you hear us okay?
Leonardo: yes
Ed: I can hear you know, yes
Leonardo: Okay, yes. I was thinking about the, you know the flow
concept, it's a concept about per page, but we don't have the concept
about particular of wisdom. I'll have an example where you take one
part of the page, you create a component that navigates that used that
navigation accordingly, in that part of the page to a strong
connection of the scope. But I found that the flow scope has its
limitations. That it required the whole page.
Ed: Yes I know, even in ADF they have a fragment concept and that is
something that we specifically left undone in 2.2. So I think that tab
flow fragment thing is exactly the common thing that fits.
Leonardo: So I stole the coding fragment. If we can do the necessary
changes in JSF we could have a concept that like a flow concept but it
doesn't work.
Ed: Alright! So that's a kinda side issue we're thinking about.
Ed: I like now that we're turning to the more technical portion of it.
So in terms of discussion, what can we do with the combined expert
groups here in the room. I guess I'll review those the thing I
mentioned in the start during our talk I talked about server push and
how it might be exposed in JSF. So for those of you that were in the
room; does that fit with what you were seeing as a use case for server
push from a Servlet perspective? Greg and Dustin?
Greg: What I consider the magic about that push at the moment is that
I think that the JSF and Servlet talking together is a really good
way, need to be on both sides of the fence there. JSF is a really
great use case of a framework that has really good knowledge about one
of the pages that have been constructed, you attract users and stuff
like that, and actually build up a really good view of what a client
might actually need to get pushed to it. From a Servlet spec point of
view I think we have to find a second use case to drive the push API
since generalizing from an example of one is pretty sucky. I think we
need to find any … As a Servlet implementor we're going to be doing a
little stuff ourselves, but our expertise is not so much in the
content generation side of things. So it be really good to find
another content generating partner to have a different world view than
JSF. Because whatever we come up with has to work out with the
complete knowledge stuff and other frameworks that have less complete
knowledge.
Ed: right!
Manfred: On that note, consult also the MVC spec please, that's
definitely also on the table for MVC if you guys want to, you know,
collaborate on the MVC side I'd really appreciate it as well.
Like some type of resource knowledge like feature?
Manfred: Well, I mean at least half of that will be the MVC angle, so
definitely the spec wise MVC angle and obviously JSF's there too.
Greg: And the browser vendors there just ended it for me, getting
HTTP2 out there, to cast out push ideas and such to see how it works.
So we got push to toy with now and it works, but we couldn't show the
demo since it's not working well on the interactions with web start. I
think we would probably need to do a phase of … we really need to
prototype and things like that.
[22:07]
Ed: Well, let's take some time right now to brainstorm. Like who
would we ask for a second viewpoint on this. CDN companies?
Greg: CDN has been very aware of push, but I don't know if they do it
from the Java perspective.
I got a buddy that does all in C++.
Ed: Well, SEO, how about that? Is there any kind of SEO angle that we
can look at for push?
[…]
Ed: Well I'm not so concerned about it, it's more of a product strategy
Ed: So it does not have to be someone who doesn't do Java, if it's
someone who does it at all. I agree with you that having only one use
case is not really validating things for the feature, to be honest.
Don't know it in great detail, but it can ask my friend. He's totally
backend CDN. So… and he's former Java, he knows C++ from Java.
Greg: So they say the intake is really quite interesting. They don't
get the intake of an xhtml request.
Ed: In your traveling HTTP working group, there has been discussions
about push, who would, what kind of spec holders do they have on here?
Greg: Not enough! It's basically been drivers by the browser vendors.
With their wanting to render the page as quickly as possible without
much concern about how that page is put together on the server side.
So I'll go through my users and things like that, and try to think of
some example of different frameworks and mingling pages. I'm horribly
out of touch actually with the different ways of assembling content.
Manfred: Would media companies be a good fit?
Greg: The use case of home pages is a classic example of how push
Ed: okay!
Manfred: Well, I was more thinking along the line of like an ABC or
NBC kind of type of things. Also literally content, like video and
audio since even those could be technically push.
Greg: I think a lot of people, the examples are driven by style.css
and logo.png. A lot of people think you'd only need push for static
content. You can push dynamic content that may vary for each and every
user. And you can push non-200 responses as well. You can push 304s,
redirections and lots of that stuff. It's not guaranteed to work in
the browser, so but yeah diverse content would be good to get
involved.
[23:21]
Shing: I think it's tricky to do it right. Because you don't know
whether the browser already downloaded that stuff.
Greg: Yes, you have modified match headers in there. It's saying that
there are cases that are hottish, but yeah it's limited knowledge. JSF
is a good use case on the one extreme, cause you can probably track
whether you pushed that resources to your users, and do something at
that level. Other environments won't have that.
Shing: Then it means we will like to build a server API that will let
JSF or whatever framework that we have to acknowledge how much
information is involved.
Greg: My view is that it's the framework's job to keep that knowledge.
After a framework it's like how much knowledge it keeps and how it
collects it, and stuff like that. But we just have to be aware that
there's going to be different models of knowledge and different levels
of knowledge and make sure their API […]. Like the first API that I
coasted up, one of the easiest I worked on, it's like cross-context
push. Part of me thinks, do we really need to propose that? Wasn't
this cross-context thing such a bad idea? Cause it's just a port of
its kind. Sort of an API I think. So we get some feeling if people are
going to be cross-context push?
Ed: you were even thinking about a broader cross-context, you were
thinking about cross-context wrt servlet context right? So why don't
you explain the concern that you have raised?
I dunno if it's a concern or just an item, but it's to whether it'll
be supported if you're crossing into your server side and aggregate
it, and then send it in a single stream to the browser, then your
connection might be better then the browser making the connection
separately. Is that supported and how is it implemented? I don't know.
I didn't have ideas on whether that's wanted or not.
Greg: We are already doing that in the Jetty demo, I'm doing this
afternoon. Actually JDK profiling in front of a web framework. When we
get a request in we simultaneously do an asynchronous request to
Webers and we are requesting these 3 filters while the push comes the
other way. And then we aggregate in the middle and push 'm all out.
Does that change the markup in order to revere to the URLs locally?
Greg: No, we haven't then, working on that one, but the issue you give
is that when you get the information about the modified request you
if I had modified the markup you, so I knew where the content was, I
can do a better job on making the embedded request for the push.
Because, if the redoes is coming without from not name, how do I make
it if modified or not the push request if I don't know when it was
last modified.
Greg: Yeah, so there's an issue there.
[26:37]
Ed: Well okay so we need to find some other justifications. I wonder
if any people on the HTTP biz working group that you've formed
relations with, that you could ask the plans to people.
Greg: Yeah, I'll go and review. And I'll get the firefox guys, get 'm
to tune in. Or make sure we keep 'm in the loop somehow. They are
making most progress in push. Probably they're doing it more internal.
Manfred: You brought up some good points though about proxies, since
obviously clients wanna pack everything up as well, so if we do any
work we need to make sure that those are at least capable of being
with that.
Greg: And there's also, proxies might slow …
Werner: I work for a whole lot of different companies that many have
issues with proxies depending on what product you use and how. For
tickets about waxing out or … do odd things.
Manfred: So that's definitely something for the Servlet, you know the…
Yeah!
[…]
Greg: I fear the proxies at the moment. I think the push detail is
making them an endangered specie. Even when there were very valid
business cases and use cases for them.
Ed: You're saying that they might basically be disintermediated by the
push detailia?
Greg: Mwoah, if you delisted […] the encryption, very hard to,
coppered bible to get in there or even you know to assemble components
within a data center to do push cases, shaping traffic in different
ways of things. If the bizarree is to two ways in. Even if you get the
TLS upload debate, you upload your TLS then you don't get the chance
to negotiate the ALTM handshake, so you don't go into that protocol
shorthand, umm the duration. And then there will be extra software
requirements and things. Very hard to get … proxy implemented …
anywhere from .. computer proxies, via proper bible proxies. Get them
to raise their voices, they're just deafening silence. IMTS
Manfred: That's why I thought bringing it up since obviously I don't
know them but I'm saying that that will definitely have an impact. If
it's not supported then you know we can do all that stuff, exactly as
we do with JSF, but if it's not supported then it won't be used.
Greg: It's also really interesting as well; I figure if most of the
deployments if JSF goes all the effort to build good knowledge about
what to push and you know what resources the client has got, it may be
to toy with an environment where HTTP doesn't summit the application
but terminates them around; you got all this knowledge so maybe we
need, you know, scattered mobiles have a concept knowledge across to
someone else who can do the push being of content. CDN or proxy to a
database, because there's got to be eventually in 10 years time
everything's gotta be HTTP/2. So if JSF goes to the effort of building
up the information it will be used a 100%. In between time, if you
build up this information and it's going to be used in 25% so you're
gonna require, that's a lot of bibles to invent to not use, so you're
wanna make sure someone can use it. If you can't use it yourself.
[30:26]
Ed: So I like to frame that as a question. Is it possible to encode
the knowledge of what a browser will be needing in such a way that
it's describable and transportable. Is that an accurate way to frame
the question?
It's caught you know in DOM ideas. The index to the DOM.
Hmmm…
[pauze]
(just trying to capture that)
[pauze]
Ed: Well, umm, since we're brainstorming here, why don't you show the
room the idea you shared with me as we were walking from your session
to this room, so we can get it on the recorder too.
Neil: How many guys do we have on the call?
Ed: Anyone on the call except for Leo?
Ian here!
Ian! Welcome!
Ian: Hey, thanks Ed!
Neil: I was just talking with Ed about how we see this technology
pendulum swing over the years; back in the days we did mainframe and
we were charged by the hour, and then we all started buying servers,
now we don't buy servers anymore and are back in the cloud and we're
paying by the hour on Amazon. We all used to build desktop
applications, and then it's no we're going to be all web, and now
we're building things for phones that are native which in a sense is a
kind of desktop application, except that it's a native client. So
anyway, then I saw an article where Twitter decided to look their
rendering, … part of the their rendering logic back to the server. And
to rely less on the javascripting in the client, because it wasn't
happening fast enough and then we're talking about the domain study
about loss and revenue when pages slow slowly right, things like that.
Neil: The idea is, in JSF we have these different phases and the
lifecycle and the last one is render response. The idea that I have is
perhaps one more phase: decorate response, where you have the
opportunity where render response would render into the server side
DOM and then decorate response would have an opportunity to invoke
Nashorn and so JSF would download any of the javascript resources that
are needed and then execute the javascript server side so that a fully
decorated HTML document is delivered to the browser and you don't have
to rely on the rendering engine of the browser for speed, anyway it
seems like, it's a challenging thing, but rendering to a server side
DOM has been done before. Icefaces has done it for 10 years now. They
did it for server side DOM-diff, I'm not suggesting that. I'm just
saying the javascript engine needs a DOM to operate against. Server
side in order to do this. That's the idea. Seems kinda like a big
ticket item you know. But I think it could be a big win and keeping
JSF -relevant-, because when we're talking about server side rendering
it's kind of an old idea. I think it's time for that old idea to get
some new life back in. Because JSF is so very good in delivering the
markup at a minimum why not fully decorate the markup, at least for
the initial download of that first page. Subsequently javascript is
actually sitting in the client, that's kind of a bigger problem to
solve, do you keep that in sync with what's going on in the server? I
dunno, but anyway that's the idea; perhaps an additional phase to the
JSF life-cycle. Or is this an idea that's better left out there in
open source land for a vendor to implement as an extension? I don't
know.
Manfred: Well, they can already do that. I mean, you can create your
own life-cycle, so you can add it if you want to.
Neil: The life-cycle factory is limited. I've had problems with that,
I tried to have a different life-cycle for different Portlet phases.
And… it didn't work. It didn't work!
Manfred: Hmmm
Neil: But that's for another time, to discuss that.
Manfred: okay
Neil: Anyway, that's the idea and I just wanted to know if anybody
thought it's worth pursuing, or if it's an hairbrain scheme.
[35:43]
Shing: Would this be on a per user basis, would be do this?
Neil: Well, it would be on a per-response basis. It could be very
computational expensive on the server and it's not something you would
want to do for all applications, you know, it's something that you
want to do if you need it. But if time is money and you can throw
hardware at the problem in order to not be CPU bound and get your
content delivered, then it's maybe a win. JSF is also tends to be used
in, something Kito said, wanted to have new staff, where JSF can't be
used in use cases where some type of JS driven, you know, some type of
crud type of application. Where the content needs to be rendered
really fast or people are losing money. Or is this more like an eBay
situation where you need to get a page to somebody so they can hit F5
really fast. I don't know if the use cases for JSF support it. But the
technology is there.
Shing: Is it after the render phase or already in XHTML, it can also
be implemented by a Filter, and then it wouldn't even have to be JSF
specific.
Neil: It could be a Servlet Filter or Portlets Filter. The problem is
that you have to parse the HTML, whereas if you render it directly
into a server side DOM it's kinda pre-parsed.
Greg: And one of the things we also should consider actually in
Servlet 0, is that Servlet 3.1 really supports the whole concept of
filtering context
Ed: How do you mean that exactly? I'm new.
Greg: It's really difficult. When you have an alpha string and you
have the write coming in you don't know the asynchronous write, or
synchronous write. And if code is written thinking they asynchronous
write or may synchronous write they won't call this ready in between
the write and though every single filter that does this by j filter
and stuff […] is this the content coming in synchronous write and they
you sit down to tell off, I'll just extend these methods. How hard can
it be?
Greg: It's a duty to to any wrapping of input stream and output stream
to make it work for both synchronous and asynchronous content, and be
efficient, and lock-free, and race free is just great. And it's almost
as if we want to justify our ability. We might need another
interception point to get out the data in a way to filter that data
and parse that data without knowing whether it's blocking or
non-blocking and without all that, I mean it's a bit of a fad anyway.
Greg: You're going to wrap the response object so that when someone
calls getOutputStream() you can wrap the output stream all for the
call gets colder and you always call the stuff. It's kinda like, you
down the stuff to pile on byte for another version, so you know, have
characters as well, It's much better than come all the way down and
have a single intercept point. I mean, at the moment the gzip filter
is the main ladder and the most contended building someone and anyone
store anyway. There are ongoing requirements to filter content then I
think what we could look at providing now we're at this point.
Ed: Okay, so to capture that: you're basically asserting and
demonstrating that Servlet 3.1 broke the way filtering is done due to
the way we insist on wrapping things a certain way.
Greg: right!
[…]
Ed: Complexified.
Greg: I like the word.
Ed: Just coined it right now
Neil: We couldn't do the server side decoration in a filter that just
makes it really hard [ed: complicated]. So one request I would have is
that we consider just adding this extra phase at the end of the
life-cycle, and then, and as a no-op, but it's there. So that it can
be taken care of. As an extension point.
[40:09]
Manfred: Is there any reason why you couldn't do it when a custom
render kit? I mean…
Neil: Uhm, well… you could do it with like a PhaseListener where
you're listening to after phase
[…]
Neil: So you could do it like that
Manfred: I mean, cause I'm a little confused, if you're talking about,
you know, the DOM, I mean, that is a representation, so, you know, if,
if you're talking about a custom render kit wouldn't that work at all?
Neil: No, actually I'm not talking about a custom render kit I'm
talking more about a custom DOM response renderer kind of thing where
the response writer is writing into a server side DOM. All your render
kits that are already out there can leverage writing into this server
side DOM but then you have this extra opportunity to decorate what's
in the server side DOM before it gets, you know, toString-ified and
written back out to the response.
Kito: I kinda like the idea of having a very … would be very
fascinating to see what you can do with a phase that actually can use
the themed javascript first before it gets send to the client. Would
be very fascinating to see.
Neil: Yeah, so, I mean, like I said I could just be phase with a
vanilla no-op out of the box but it's there, or we do something with
it.
Manfred: The complexity in adding is a little but strictly because of
the fact that you're state saving as well, when are you going to do
that? You know, because that is not really the last part. I mean
render response is really render response plus… [multiple people at
the same time:] State saving!
Manfred: Are you going to plug in-between?
Or maybe after?
Neil: It would be totally after. It's simply decorating the HTML and …
I can't see how it could affect state
Manfred: Well it shouldn't, I mean that is
Neil: It should not be affecting state, it's just simply affecting the
rendered markup
Manfred: Well, I just wanted to make that clear, since otherwise you
know it's like historically speaking state saving -is- the last step
of the entire life-cycle. So, if you're gonna change that then this is
in my opinion a rather fundamental change. Even if it may not call
anything, it's still a very fundamental change.
Neil: Technically it's not part of the final stage of render response
Manfred: yes. That's kind of the problem is that you know restore
view, when we have one…
Neil: right
Manfred: … which is really restoring state, cause that's really what
it is, you don't have a state to pay at all. So that's kind of the
disjunct there. That's why I'm bringing it up. If you're wanting to
add an additional phase, I'm not sure if you do, you'll leave it only
at that point. That's like …
Ed: Maybe not save state based
Maybe not, maybe else, makes it … add this life-cyle and manipulate
this life-cycle. Cause not it's hard to do right?
Neil: And this would be the prime approach. So life-cycle that
executes, executed everything, -except- the render. Which I think is
primarily for Portlets, right? So that it could be broken up over it
[…] original design … this would be just like that; an additional call
that you have to put in a Faces servlet or in a Portlet bridge. I have
essentially finished talking about it. It's fine, get the idea out of
here, see if anybody thought it's worth doing. Because -that- would
bring the technology pendulum swing back to JSF.
Neil: Executing javascript on the server something two companies
already are doing, six, seven years ago, now it's all the rage. It's
really big. Server side javascript is huge. And with Nashorn and FTE,
it seems like all starts are aligning for something like this.
I'm not reading into it now, but at the booth, Ian is going to be
talking about the idea of doing of how JSF could integrate with client
side frameworks like Angular and things like that. And the only
proposal that I have really was just to view component rendering in
JSON as opposed to XML which is a kind of no-brainer; a lot faster and
a lot more lite you know, the side, the pale side of rendering during
a data table is often ridiculous … machines and properties … rows or
something like that.
Neil: I've got a colleague at LifeRay and in our javascript library at
LOEY we have a data table javascript component that does exactly that;
it gets json back and then you know paints the table based on the JSON
and my colleague, I don't know if he wrote it or not, but he was
saying: "You know it's just that on the iPad it's just too slow, you
know it's blinking, and this and that. He said: I'd much render the
HTML table on the server and then […]". I know a framework that does
that … initial rendering that absolutely one of the things that I like
about JSF, the initial render … get that upfront!
Talking about an update [..]
In that situation I don't want the whole table and all forty rows back
Manfred: That's the whole intend of getting a partial execution you
want small packages
[…]
[46:00]
Kito: I got a client initially have small browsers that even updating
all the buttons on the screen was noticeable, so we could have
optimized the table […] button, render the whole button again.
So you just replaced the stealth hack?
Yeah, yeah!
And a lot of these components have client side javascipt anyway. Like,
and they can -do- it, like it's totally possible. But it'd be nice to
have a build-in hook.
Ed: That one I can totally see.
Yeah, like you can render a JSP now.
Kito: I have one thing that I like to validate with the expert group,
and that concerns browser sniffing.
Manfred: Haha, oh my
Kito: I know it's not a very complicated issue, but I feel like there
should be… you should not have to find a third party library if you
want to find more about the device […]
You have to keep a database like duce war fall, it's a database you
pay money for.
Manfred: That's really tied back to the html working group and which
companies are involved in that; what user agents they're going to
send. Really that comes down to the overarching industries. Can we get
them to a point where they're publishing that in a way that's
consumable. […] relying on something […]
Greg: […] capability is […] whether […]
Greg: […] they all supported you know […]
Ed: I didn't even know this, but apparently there's been a descoping
of a lot of features in HTML5, that were formerly in the HTML5 spec,
that are now going to be put in … they already were separate
sub-specs, but now they're not a part of HTML5 anymore. So, apparently
somebody at W3C, there's this … the other day, H-T-M-L… 5 …. yeah,
Google search for HTML5 plan 2014, it's the first hit for me. "HTML5
plan 2014" and it says here… "The HTML Working Group Chairs and the
Protocols and Formats WG Chair have been asked by the W3C Team to
provide a credible plan to get HTML5 to Recommendation status by 2014.
Challenges remain in achieving this goal".
[48:27]
Ed: And, so what they basically did was they left a bunch of stuff
out, like web sockets server side events, really fundamental things
that were in HTML5 are not a part of it anymore. And so this document
here justifies, their decision to do that by saying modularity. HTML5
is good at modularity.
[laughter]
Ed: Look at the document!
Well played!
Ed: So many technologies that were originally defined in HTML5 are now
defined in separate specifications. Mircodata, Canvas, Web Messaging,
Web Workers, Web Storage, WebSocket, …
So what are they including?
[…]
Ed: …, WebRTC,
Shadow DOM is out!
Ed: So, this ties into browser detection. Because this is going to
make it even -harder-!!!
Ken: Stuff that I wonder, every time you want to get more information
about the client, you're going to find some third party libraries.
You'll find lot's of information in a pool which is database, more
information like …
Manfred: I got a blunt question for you, I mean, how does eBay deal with it?
Ken: Uhm, detection, that's the ideal, but there's some standard
mechanism beyond the Servlet, there are other standards that we would
implement or that others would implement, maybe we would eventually
converge on… even if the data isn't part of it there'll be at least an
API that developers can write against to to get it and they plug-in… I
dunno… That was JSF originally did we said this is the standard so the
tool developers can write against it to build applications … variance
to …
Manfred: So from the Servlet API perspective does, you know I mean …
Ed: I like to rule it out: too low level or too …
Woh! I think Servlets are fine
Greg: If, I mean, within the server we actually do do a little user
agents to catch html builds anyway, because… there are some HTTP
victors … probably implemented in some browsers it's like putting it
into the API doesn't mean we can solve the problems. If Don gave me
the lead up, big enough, to solve the problem, then I happily put it
into the API.
Greg: Who got the carrot and the stick that's gonna make the browser
vendors lay it out what their capabilities are?
Manfred: But coming back to the HTML5 working group, obviously they
realize that they have to deliver something. To me it sounds like
unfortunately browser sniffing probably never make it, it involving
too many partners.
[small pauze]
Ed: right… that's a problem we have to live with
Manfred: Well, I guess it depends on what kind of websites you're
doing. If you're doing a website that requires login you can make them
set their preferences I guess. If you don't do that yet then […]
Ken: This is another sort of random thought; one of the things that we
get with replying frameworks like JSF is that we get a lot of
abstraction. We could even with things like, you know, there's HTML
templating, where that is in HTML5 right now, HTML5 template we could
…
Ed: The template tag is still in there
Ken: So yo could create your page name, 5 2 pounds, extract yourself.
[laughter] But we could actually do html5 templating at one there's a
lot of interesting and worry at life without things you could look at
like that as well. But I think that that's sort of where JSF's
strength lies and what you can do on the server that can you can't do
forward on the client totally javascript application… requires.
There was talk at one point by ed about breaking out component […] I
know you're focussed on HTTP2 support and other things, is the pro
to-thing Kito is talking about a more quite renderer side of things,
but I think it's very important to adoption of JSF and the success. I
don't know how to get resources to it cause I agree with Kito that the
effect of having ajax or JSON for having a better render kit that to
do that. We're never getting it done, it we're not doing it in this
one when are we going to do it to come along with improvements?
Manfred: What about making it easier to have different renderers. I
mean, it's fairly easy already but maybe we can make it even easier.
Yeah, but that's more enthusiastic, more interesting one.
Ed: But the JSON rendering thing you're talking about, that's not a
render kit concern, that's more of a …
Kito: More of a hook!
Manfred: In general it's like what we talked about before, it's like
you know the scope is much, yeah it's limited but are there areas that
you guys think we can help you out so that it becomes easier to
plug-in to the framework that before was a little bit awkward?
Right…
Ken: It's definitely you through the JSON rendering like that I can
actually be aware of I did it but I didn't know where you where.
Right!
Ken: Hook like you very different, I didn't gave a very specific case
because of the general case
So the product rendering concern wasn't it the renderer saying, ah I'm
an AJAX request I'm gonna render JSON right?
Kito: yeah, I think it would be a rendering concern, but it wouldn't
be a render -kit-
Kito: First thing a separate renderer perse [EDIT Manfred: "Meaning it
would not be a render-kit. Just a renderer"]
Manfred: That's kind of the disjunct between you know partial
execution of the you know lifecycle, partial vs full. In my opinion it
should've been but that's another debate. Because that would been
easier to support other use cases. You know, because in all reality if
you really look at the partial execution it really is a full execution
the only difference is … [kito: yeah!] depending on whether you're
pumping that one a bit up. You know, so, then JSON would be, would
have been another opportunity. Because the same case boom! I'm
rendering this out now. So, that's why I'm saying with if we can
deliver the correct kind of work step, make that possible, then you
know if you don't wanna do JSON hey if you wanna render out a PDF, I
don't care. You know I mean, but right now, you know, it, it requires
more work.
[55:45]
[EDIT Manfred: "I was trying to explain that from my perspective a
Partial execution is really another lifecycle. And unfortunately we
decided back in the day to bolt it in instead of making it its own
lifecycle.
And that’s why I was talking about the render kit here. Cause from my
perspective JSON vs XML is a choice of the Partial lifecycle."]
Right, yeah, and it has to be hooked on the client too.
Ken: […] because you want to have a place where the tailor be able to
get it back
Is your concern about the big … a big partial response containing all
the TRs and TDs, is it the size [some chatter] or is it the big DOM
replacement?
Kito: It's actually the size of the response
Otherwise when I worked with people that I counted on leaving this
place 50k in saturation and came back. Got it?
Kito: Fully, some of that could be done with a component?
[56:19]
Greg: Just we're almost out of time. Can I stop you, because before
you move out there's one other really important thing I think we
should bring to the groups, is that the… the whole area of priority I
think, if we don't do anything about it (sorry to change subjects but
I gotta run) what's going to happen is that the browsers will stand
without priority and the social will know about it and we'll just
block. The browsers don't want that now.
Ed: Stream party
Greg: Stream party. If we don't do anything about it, the first thing
we'll know about it is that we got committed all the resources to
generating a response we try to rub a response out and we just block
after writing a few little bytes, because it's low priority and
everything else is progressing and we can't progress that stream and
so given HTTP2 has the capabilities to spray 30, 40 (pity), 80
requests per browser/server, do we really wanna go processing all that
daily requests. We only need to find out the render stage, it's a low
priority request and we really shouldn't committed all that time
generating it, and we so, you know, getting that priority information
if it's coming from the client and maybe not dispa.. and maybe trying
to dispatch in priority order, and once you… then the other thread
comes into it's mechanical sympathy. If you got 30 cores and you got 1
client sends you 30 requests all you need to push stage response to
them, do you really want to spray those across all that 30 cores and
hot up the same user instance the same view, if every.. somebody's
core and they all came to the same synchronization thing. Or do we
wanna be a little bit smarter about our scheduling and trying to be
say one or two cores for that one user, so that the other cores have
hot caches for other people. And if we -don't- do anything about
priorities and we -don't- think about the scheduling then we are gonna
end up with, you know, 30 or 40 requests sprayed across all that
cores, caches will never be hot, umm, and we'll be generating from
cold caches content that the browser doesn't want at some point.
[58:22]
Ed: right
Greg: And, yet, so that's a really big problem identification and I
have -no- idea how to solve it. I mean in Jetty we're trying to do
some smart scheduling algorithms we call "equally chill", but I don't
know [laughter] if you start doing something you in the same port can
finish it, that I think there's only so much you can do at that level
and I think that's why bringing it into JSF awareness, that, you know,
if you're gonna get priorities that might… you may wanna bring in some
scheduling and dispatch and all that and that may bring you back to
what you need from the Servlet API in order to achieve that if you
know you can tell it. Don't bother to expect a lead request from me I
know the low priority, deal with even dispatches you know print the
[de-tums]
Hmmm
Manfred: Which you know ties back into what JSF does with regards to,
you know, the AJAX response model. They already have some, -SOME-
small capability to say, yeah whatever! You know, but that might be
another area that, you know, we would love EG involvement to see hey
can we get that to a better state where, you know it's more
configurable or sensible action.
Ed: okay! So this was a good kickoff meeting. For JSF we never really
were a group that does lots of conference calls, so umm I kinda like
it that way. And for Servlet, do you guys do lots of conference calls
in the past?
Greg: I don't think I can remember one
We are mostly asynchronous!
Ed: So, that's it for this one! We'll maybe do some occasionally. As
the need arises. But, I think this was a fun and productive thing and
we do have some action items, to find some use case validations for
server push. So that's the biggest thing I can see to take away. So
all right, thank you everyone!
* End of transcript *
Kind regards,
Arjan