I think it is time to decide on the criteria for when OOPHM should get
merged to trunk so we can be working down that list. Since we forked 1.6
and the trunk is available for 2.0 stuff, I think the criteria should be
when developers working from trunk can switch to OOPHM with minimal
disruption. Here are the things I think need to be addressed:
- FF1.5/FF2 support -- a number of widely-used Linux distributions still
do not have FF3 available, including many heavily used inside enterprises.
- Testing - existing hosted mode runs in headless by default, but since
we aren't embedding the browser with OOPHM we can't easily do that. On Mac
and Windows that leads to a problem in that the window pops up and steals
focus. Possibilities:
- For Linux, you can run Selenium-RC inside an Xvfb display and
everything works perfectly (arguably better than before).
However, I don't
know how to do something similar on Mac OSX or Windows (at least
on Windows
it seems like it should be possible to emulate all of GDI, but
it would be
tons of work and I am not aware of it being done -- perhaps Wine
code could
be useful).
- Use a SWT-embedded browser as an OOPHM client. The bad part of this
is we are still in the business of distributing native binaries
(besides the
plugins) and have 32/64-bit issues, plus we would still be
testing against
an old browser on Linux.
- Allow the old SWT-based code to be selected at runtime, which avoids
the OOPHM wire protocol but otherwise has the issues above.
- In general, it only pops up once per test run and you can iconify it
and go on, so maybe it isn't a big deal.
- Swing UI runnable on JDK 1.5 -- the solution I used for adding close
tab buttons turns out to have been added in 1.6, so it needs to be rewritten
using only methods on 1.5. From a bit of research, this is really nasty
code but a lot of people have done it so it shouldn't be too big a deal to
do.
- Removing missing plugin warning when using XPCOM (perhaps by
dynamically injecting tags in hosted.html or splitting hosted.html into
platform-specific bits).
- Implement whitelist/permissions checking for OOPHM connections. This
probably also means we have a preferences UI for setting this.
- UI mocked parts implemented or removed.
Here are other to-do items which I think should not be blocking for getting
it into trunk:
- Chrome plugin
- handle exceptions on field get/set
- more robust dealing with dropped connections
- code refactor to pull out more common code between plugins
Comments on these or suggestions of other things that should be considered?
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
