[Mulgara-general] firefox bug and server config

Fri Sep 4 20:06:48 UTC 2009

On Fri, Sep 4, 2009 at 1:04 PM, Paul Gearon <gearon at ieee.org> wrote:

> On Fri, Sep 4, 2009 at 10:20 AM, Gregg Reynolds <dev at mobileink.com> wrote:
> > Hi,
> >
> > I'm working on a simple web page and javascript for exploring Mulgara.  I
> > seem to have run into a firefox bug, whereby a GET transaction is
> completed
> > (readyState == 4) but the status == 0.  I'm sending the get request to a
> > vanilla mulgara instance on localhost:8080 that I know works.  In
> > LiveHTTPHeaders I can see the request and response, both of which look
> > fine.  But the XMLHttpRequest object seems to be discarding the data.
> This
> > is on OS X 10.5.8, FF 3.5.2.
>
> This is an area I haven't really explored so I'll need to get up to speed.
>

Well, having spent about 16 out of the last 24 hours of my life trying to
figure out why my browser wasn't behaving the way I thought it should, let
me offer you the following advice:

a) you're just gonna have to hack for at a web page that makes
xmlhttprequests, and deal with the weirdness and the general
untrustworthiness of the documentation.

b)
http://www.opensourcery.com/blog/marcus-estes/taking-gloves-xmlhttprequest
http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/
https://developer.mozilla.org/En/Server-Side_Access_Control

and, in general, a web search for cross-site, xmlhttprequest, etc., will be
productive.  The bit of code I borrowed is at
http://arunranga.com/examples/access-control/

c) in my estimation, it would be a major Attaboy for Mulgara to provide some
Ajax stuff, both on the wiki and in the distribution, showing how to cadge
data out of a Mulgara using Ajax techniques.  I can't say I know the
marketplace especially well, but I have looked around at a lot of RDF
engines, and I don't recall ever seeing anything in the way of examples
other than low-level motorhead kind of stuff.

> I've been beating my head on this for about eight hours now and I'm
> > completely flummoxed (how I hate software!).  My suspicion however is
> that
> > this might be connected to the new support
> > (https://developer.mozilla.org/En/HTTP_access_control) for the CORS
> > standard.  I.e., if the mulgara response were to include the
> > "Access-Control-Allow-Origin" header, it might possibly maybe work.  (See
> it
> > in action, with LiveHTTPHeaders on, at
> > http://arunranga.com/examples/access-control/simpleXSInvocation.html
> Dunno
> > what else to try at this point.
>
> Do you know exactly what is going on between FF and Mulgara? This
> might provide some further hints.  If you're not using it already,
> then go through HTTP Tracer:
>  http://simile.mit.edu/wiki/HTTPTracer
>

Man, I coulda used that.  LiveHTTP Headers is great, but there's something
iffy about using a tool to monitor itself.  I did cranked up wireshark but
immediately ran away whimpering.  HTTPTracer looks like exactly what I need.
Thanks!

I wasn't absolutely sure about what was happening, but enabled FF's
LiveHTTPHeaders and experimented with a lot of different webpages, and in
the end decided it was probably accurately reporting the fact that FF was
issuing a request, and the server was responding appropriately, but FF was
puking the response.

> > The problem is I have no idea how to configure Jetty and I'm hoping
> somebody
> > on the list does and is willing to save me the trouble of learning.  ;)
>
> I know a little, but I'm not an expert in any sense of the word.
>

That's a Good Thing.  There's something terribly, cosmically wrong about a
configuration language that uses XML to encode a programming language,
especially if said language is as supernaturally ugly as Java.  But I
digress.

> The other thing to be aware of is the URLs that you're using. I had
> been successfully using http://localhost:8080/sparql?query=.... using
> wget, but it failed inexplicably on cURL. It turned out that the Jetty
> has to register the webapp with a trailing / character, and using it
> without would result in a redirect. So the safe URL to use was
> http://localhost:8080/sparql/?query=....
>
> The combination of /? looks strange to me, but I guess it makes sense.
>

Suggestion: pls put such stuff on the wiki.  It's precisely such little bits
of info that frustrated users would kill for.  And down the road it's
material for the "Definitive Guide to Mulgara".

By the way, do you have an image, suitable for mascotry, of a mulgara?

> FWIW, the little doo-dad I'm building (which could compete with the iTQL
> > CLI, if I could just get Firefox to cooperate!) is at
> > http://bitbucket.org/gar/mulligan/overview/ in case anybody's
> interested.
>
> How does it compare to the WebUI? (you HAVE used the WebUI, right?)
>

Ahem!  Of course I have!  It's not so useful for me, though, I need to go
against the SPARQL and TQL interfaces.   My application must allow the user
to manipulate data graphically.  WebUI is a classic HTML interface, but I
need the granularity of XMLHTTPrequest.  I need to fetch a bunch of data,
present it to the user in tabular form, and allow the user to manipulate the
table at-will, using drag-n-drop.  The fetch some other data, add it to the
GUI, etc.  Fetching data means executing a SPARQL query in this case; I
suppose I could do that with traditional HTML submit logic, but
XMLHttpRequest seems a much better solution.  All the cool kids do it.  I
also need to provide a stand-alone package, which is why (among other
reasons) Mulgara is attractive.   I envision a distribution that consists of
Mulgara configured to run locally and a collection of XHTML pages,
Javascript and CSS that will hit the Mulgara server for data and present it
prettily to the user.

The basic idea for Mulligan is just that anybody in my situation, who needs
to convince himself he knows what's going on both with SPARQL query language
and the protocol (and TQL or whatever complementary language the service
involved requires), well, he could use a simple tool to experiment, and see
what's going on explicitly.  I started out doing this with cURL, but,
obviously something with better eye-candy will be more attractive to my
end-users.  So, since we can do just about everything we need to do with
Mulgara over HTTP, be it SPARQL or TQL, why not slap a slick UI on it (with,
in this case, jQuery)?  Don't get me wrong, I LOVE the command line, but you
can't expect that from everybody.  One of the things I'd like to do with
Mulligan is generate cURL (or other) command line parameters from the query
specified via the GUI.

I started out just wanting to come up with a nice, easy, GUI interface to
Mulgara for my client, but then I realized it was turning in to a general
HTTP explorer, and it could easily be turned into a general-purpose
RDF/OWL/SPARQL/whatever explorer.  No promises, though; but if I can get the
XMLHttpRequest stuff working I promise I will add support for all the TQL
primitives (not that difficult, actually).

Thanks,

gregg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-general/attachments/20090904/ff652a85/attachment.htm>