<br><br><div class="gmail_quote">On Tue, Nov 20, 2012 at 11:38 AM, Max Rydahl Andersen <span dir="ltr"><<a href="mailto:max.andersen@redhat.com" target="_blank">max.andersen@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>> > The idea is to add to VPE the must have features, like the support of JavaScript and HTML5 and the support of 64-bit JVM on all OS. And get rid of all less important features and the features that do not work very well (i.e. editing - that is why we call it 'viewer').<br>
><br>
> I know it is just a name but this is still going to be part of an *editor* - its just that the visual part is not editable.<br>
><br>
> For me VPE still works, its a Visual Preview Editor ;)<br>
> Ha-ha. Ok, but it would be not bad if we had a name to distinguish it from 'classic' VPE.<br>
<br>
</div>True, so VPV is a part of VPE ? :)<br></blockquote><div>Would be a part of vpe component on github, but it is completely independent.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What is your plans for making it available - as an extra tab on VPE or even as a separate view ?<br></blockquote><div>For the beginning, my plan is to create a separate Preview View. The problem with views is that we cannot attach them to an editor. It will be like JavaDocs View, which is absolute unnecessary when a non Java editor is used. So it would be good to create a new tab in the VPE editor later.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> > • Leave XULRunner DOM based templates as is and create wrappers for browser nodes.<br>
> > - Simpler than the previous approach, but slower and requires to build visual DOM in the UI thread.<br>
><br>
> Okey so how do we handle this migration ?<br>
><br>
> If its a rewrite I assume the two will be able to coexist ?<br>
> Yes, I assume they two will coexist until we decide that the new one is mature enough to completely replace the old one and XULRunner things.<br>
<br>
</div>we've seen a few issues with the browsersim not working all smooth with WebKit, but I guess for VPV this is less of a concern since we will simply just<br>
be using whatever built-into-eclipse browser is enabled by the user on his platform, correct?<br></blockquote><div>Yeah, it will use any browser. But of course, each browser, has its own features/bugs which should be taken into account when creating the viewer. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> If it is a rewrite we should make sure to move everything that is not public api into internal packages.<br>
> Will do it.<br>
<br>
</div>Would also be good to make an effort on making the API to add support for other libraries more approachable than previous VPE.<br>
i.e. documented API's, example of how to do it etc.<br></blockquote><div>Agree. We could also make creation of templates more approachable by creating a simpler templating system. Now in VPE only Java and XML tamples are allowed. But we could allow also something like <a href="http://ejohn.org/blog/javascript-micro-templating/">javascript micro-templating</a>.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> > We are going to open a TCP port, what about security?<br>
> ><br>
> > No problem here. Java allows to restrict connections to localhost only:<br>
> > new ServerSocket(8383, 0, InetAddress.getByName("localhost"))<br>
> > At least the standard Windows firewall does not worry and does not show the “Security alert” pop-up.<br>
><br>
> don't we need to have a http server for each page that is open ?<br>
><br>
> i.e. if you have the same page name (i.e. index.html and ../images/funky.gif) ...but different content for your project.<br>
><br>
> How is that handled?<br>
> One http server for one eclipse instance. Pages on the server will be available under paths like localhost:xxxx/project/pathtopage/page.jsp. We could also dispose the server when no VPE editor is opened.<br>
<br>
</div>How about absolute relative paths like "/images/funky.png" - I guess that will be handled the same way as before where the href's are rewritten to have a proper "root" ?<br></blockquote><div>
Good question. I just forget about this root-relative case.</div><div>It looks like one server per viewer or at least one server per workspace is needed to handle it. I assume, that our users may have several editors opened, so one server with changing root directory is not an option.</div>
<div>Obvious drawbacks of multiple servers are:</div><div>- we have to manage their creation/disposal</div><div>- these servers will consume more resources (not much, but at least a port and a connection-waiting thread per each)</div>
<div>- pages from different projects will not be able communicate with each other, because of same-origin policy. (Anyway, now I am not planning that they will communicate even on one server per workspace.) </div><div>These seem to be not very big problems, probably it is worth it to create a server per editor, which should be pretty easy to maintain.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
btw. who's github branch are you doing this work in ? Would be nice to take a look and try run it from time to time.<br></blockquote><div>Now it scaterred locally and in old svn workspaces. I will create a vpv branch in github/yradtsevich/jbosstools-vpe.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
/max</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Best Regards,</div><div>Yahor Radtsevich</div><br>