On Tue, Nov 20, 2012 at 11:38 AM, Max Rydahl Andersen
<max.andersen@redhat.com> wrote:
> > 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').
>
> 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.
>
> For me VPE still works, its a Visual Preview Editor ;)
> Ha-ha. Ok, but it would be not bad if we had a name to distinguish it from 'classic' VPE.
True, so VPV is a part of VPE ? :)
Would be a part of vpe component on github, but it is completely independent.
What is your plans for making it available - as an extra tab on VPE or even as a separate view ?
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.
> > • Leave XULRunner DOM based templates as is and create wrappers for browser nodes.
> > - Simpler than the previous approach, but slower and requires to build visual DOM in the UI thread.
>
> Okey so how do we handle this migration ?
>
> If its a rewrite I assume the two will be able to coexist ?
> 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.
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
be using whatever built-into-eclipse browser is enabled by the user on his platform, correct?
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.
> If it is a rewrite we should make sure to move everything that is not public api into internal packages.
> Will do it.
Would also be good to make an effort on making the API to add support for other libraries more approachable than previous VPE.
i.e. documented API's, example of how to do it etc.
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
javascript micro-templating.
> > We are going to open a TCP port, what about security?
> >
> > No problem here. Java allows to restrict connections to localhost only:
> > new ServerSocket(8383, 0, InetAddress.getByName("localhost"))
> > At least the standard Windows firewall does not worry and does not show the “Security alert” pop-up.
>
> don't we need to have a http server for each page that is open ?
>
> i.e. if you have the same page name (i.e. index.html and ../images/funky.gif) ...but different content for your project.
>
> How is that handled?
> 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.
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" ?
Good question. I just forget about this root-relative case.
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.
Obvious drawbacks of multiple servers are:
- we have to manage their creation/disposal
- these servers will consume more resources (not much, but at least a port and a connection-waiting thread per each)
- 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.)
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.
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.
Now it scaterred locally and in old svn workspaces. I will create a vpv branch in github/yradtsevich/jbosstools-vpe.
/max