[Mulgara-general] firefox bug and server config

[Paul Gearon]

On Fri, Sep 4, 2009 at 4:06 PM, Gregg Reynolds <dev at mobileink.com> wrote:
> On Fri, Sep 4, 2009 at 1:04 PM, Paul Gearon <gearon at ieee.org> wrote:

<snip/>
>> 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/

Ouch. I'm trying to catch up on my time away (while I moved) so I
really don't see that I'll have much opportunity to get to something
so involved right now.

> 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.

Well, Mulgara is supposed to be offering infrastructure, on which
everything else should be built. You're talking about stuff further up
the stack, which is why we don't usually look at that sort of thing.
But facilitating AJAX would certainly be a Good Thing (TM).

>> > 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!

No problem. Simile have a few handy projects.

> 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.

I'm not sure I follow your complaint here. You may be talking about
something I haven't had to configure before (encoding a programming
language? You mean, something like an AST of Java in XML?). On the
other hand, I've definitely decided that I don't like Java either.
:-)

>> 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".

That's what I created the wiki for. You'll note that the page on the
REST interface discusses this. It initially gave the full path for the
URLs (including the /) back on April 20, but then 17 minutes after
first writing the page I updated it to explicitly mention that the
paths had to end with a slash character.

http://mulgara.org/trac/wiki/RESTInterface

That said, it can be hard to find things in documentation at the best
of times. I'd love to set it up to make it easy for people to find
what they need, but I really don't know how. It's not feasible to just
tell people that something is "in the wiki" if they have to read the
whole thing before they find what they need.

> 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.

OK. It's just that describing it as competing with the CLI made it
sound like a duplication here. Personally, I never use the CLI
anymore. I either use the WebUI or the REST interfaces.

> 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).

It might be worth making this work with SPARQL2, since almost
everything in TQL will be present there, and it will be more portable.
SPARQL2 is a long way from completion, but a lot of it is pretty much
worked out already (eg. Look at SPARQL/Update from Jena).

Regards,
Paul Gearon