Re: Putting Splinter on bugzilla.gnome.org

[Owen Taylor <otaylor redhat com>]

On Wed, 2009-10-07 at 11:27 +0200, Olav Vitters wrote:
> On Sun, Oct 04, 2009 at 11:02:36PM -0400, Owen Taylor wrote:
> >  * A Bugzilla extension for tight integration:
> > 
> >    - Links from review comments to the review
> >    - Links from the attachment table to review pages
> >    - Posting reviews with attachment status changes doesn't
> >      send two emails.
> >    - Integrated appearance (Bugzilla header/footer)
> 
> It is an extension that relies on something being installed on the
> server? How does Splinter connect with Bugzilla? Why have splinter be
> seperate? Shouldn't everything just stay within the Bugzilla extension?

Well, two things here:

 - I don't want Splinter to be bugzilla.gnome.org specific. So it
   shouldn't be just checked into our bzr repository under extensions/.

 - To keep the (large amounts) of Javascript manageable, it's maintained
   in separate files then "compiled" into a single file. This means that
   more than a simple checkout into extensions/ is needed.

So the way I set it up is that you do a 
'make install BUGZILLA_ROOT=/path/to/bugzilla'. 

But it really is structurally just a bugzilla extension (with a ton of
Javascript code in it.) Or is that way when you run it as an extension -
there's also a standalone "proxy" mode for development.

> What happens if you use an old browser btw? I don't want it to appear if
> you do not have the right browser. Further, if someone still posts the
> link, it should fall back properly (e.g. display an warning). At the
> moment it is very confusing if you see it in IE7.

Well, depends on the old browser - if your browser just doesn't support
DOM Storage you just don't get saved drafts - if you leave the page you
lose your in-progress review.

Or that's what's supposed to happen. Like any web page, it probably
doesn't work perfectly cross-browser without some testing and work.
I'm not completely sure how hard IE7 is going to be - I forget the
capabilities and limitations there, but it's certainly possible to get
to work Epiphany/Chrome/IE8/Safari

If you have something old and non-conformant like IE6 the page probably
just falls apart. The intersection of IE6 users and people who are
viewing and reviewing patches in GNOME bugzilla is empty.

I can put some work in on testing and fixing on other browsers than
Firefox and adding warnings if you are using IE6 ... maybe not
immediately but soon.

> >     http://splinter.fishsoup.net/help.html
> > 
> > I have more stuff I want to do with it eventually (allow specifying what
> > lines are being commented, keynav, getting extra context from Git,
> > tracking of what patches obsolete what, etc), but I think it's useful as
> > is and what I need most is user feedback.
> 
> > My thought at this point is to just to go ahead and install it onto
> > bugzilla.gnome.org later this week once the GNOME Shell 2.28.0 preview
> > release is out the door. There's always a chance to break something, but
> > I think it's pretty small here and I'll be around to fix anything I
> > break.
> 
> We'll need to figure out how to properly handle that extension. This as
> I want everything in one module, no mix of different things. Perhaps you
> should commit the extension to the Bzr repos of b.g.o.

When used as an extension, all the Splinter Javascript/HTML is "part of
the extension" - there's not really a separate extension that could be
checked into the b.g.o code.

> Further, splinter itself should be on git.gnome.org; I saw a typo in a
> comment in the webservice part which I couldn't fix.

Yeah, I mentioned moving it in the earlier private mail I sent. I'm
happy to do that, I just don't want it merged into our Bugzilla bzr
branch.

> btw: Bugzilla HEAD attachment.cgi is a bit nicer.

If attachment.cgi&action=edit has a text area bigger than 10 rows by 4
columns, everybody will cheer.

> I did wonder why you repeated the login method in the webservice part.

Are you think thinking of the Splinter.info() method? That returns:

  { 'version': 1,
    'logged_in': true,
    'login': otaylor redhat com,
    'name': "Owen Taylor" }

The version is the Splinter extension API version. The rest of it is
stuff that there *should* be a way to retrieve in the standard Bugzilla
RPC methods, but isn't. (Having it here does save a round-trip, but I
wouldn't have duplicated it if it was available.)

So far I'm trying to make things work with stock Bugzilla 3.4, so I
don't want to patching the standard webservices and depending on that.

The call to Bugzilla::login in:

 my $user = Bugzilla->login;

Doesn't set new cookies or check the password or anything, it's just the
standard way to get the login information from the existing cookies sent
with the request.

> > Yell now if you object.
> 
> Seems ok, just wonder about the Splinter <-> Bugzilla interaction. How
> Splinter retrieves information. I see Splinter->Bugzilla is just
> XML-RPC, wonder about Bugzilla->Splinter.

Splinter just uses xmlHttpRequest to fetch:

 /show_bug.cgi?ctype=xml
 /attachment.cgi?action=view

To get bug and attachment data.

- Owen