Thanks Arjan, this will be helpful!
Best Regards
Josh Juneau
juneau001_at_gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
On Fri, Oct 17, 2014 at 5:30 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>