Alf Eaton wrote:
> On 25 Aug 2005, at 10:38, Danny Ayers wrote:
>
>> Alf Eaton's done a Greasemonkey script to extract RDF from XHTML
>> microformats:
>>
>> http://hublog.hubmed.org/archives/001187.html
>>
>
> But I hadn't posted it here yet as I wasn't sure how it related to
> Piggy Bank :-)
>
> This was why I was asking about a trigger for getting RDF from
> Javascript into Piggy Bank - the script ends up with the RDF/XML as a
> DOM fragment or a data: URI, neither of which Piggy Bank picks up, so I
> was trying to find the easiest way to get around this (or maybe rewrite
> the script as a Piggy Bank screen scraper, but that still ends up at
> the same situation after doing the XSLT transformation).
Hmmm, I found myself in a similar situation for the DSpace scraper, I
had a working xslt scraper but needed some more functinality and decided
to port it to javascript.
We currently don't have a method in the 'module' component that is
available in the javascript scraper environment to pass a DOM fragment,
but it would indeed be nice to have (as we could, for example, have
parts of the scraper use xslt and others parts use javascript)
As for giving a hook from greasemonkey to piggybank: greasemonkey goes a
*LONG* way to make sure that you can't access anything from the internal
mozilla infrastructure that wasn't given to you (and wrapped!).
This means that you can't go inside the xpcom layer and fetch an
instance of the piggybank component running because greasemonkey doesn't
allow you to.
What we *COULD* do, is to enable 'semantic-web-like' functionality
inside your own piggybank so that your greasemonkey script can use HTTP
POST to injest the RDF/XML via AJAX into your local store. This is
trivial and we need it for the integration of Ryan's POI anyway.
Two problems though:
1) we default to port number 1978, but in piggybank 2.1 the user will
be able to change it (to avoid conflict with other software running on
that port). If this port is changed, there is no way for the
greasemonkey script to discover if the fact that no web server is
listening on that port means that piggybank is not available or that is
running somewhere else. It's also true that the greasemonkey script
might ask you for a port number in case the default upload fails.
2) allowing 'POST' to inject into your piggy-bank allows pretty much
any application running on your machine to perform this. This is already
aa security concern for privacy (for example, on a system running
multiple users, everybody can connect to 127.0.0.1 even those logged in
with another username than yours!! A way to solve this problem
effectively is to have piggybank do all HTTP traffic authenticated,
asking you for a password (which then mozilla can later remember just
like it does with other web sites!). Again, this moves us to the
previous point: the greasemonkey script user will have to ask you for
this password in a dialog box before the script can communicate with the
local piggybank (the same would be true for a semantic bank). Of course,
we could configure this behavior so if you didn't think your 127.0.0.1
could be intruded (say in your own personal laptop) you could get away
with this.
Another way would be to allow greasemonkey to have other firefox
extensions talk to it and inject objects in particular script's
contexts. But this requires some solidity in the greasemonkey API which
I wouldn't commit to myself at this early stage of R&D, if I were in
their shoes.
But if you have other suggestions, I'm all ears, of course.
--
Stefano Mazzocchi
Research Scientist Digital Libraries Research Group
Massachusetts Institute of Technology location: E25-131C
77 Massachusetts Ave telephone: +1 (617) 253-1096
Cambridge, MA 02139-4307 email: stefanom at mit . edu
-------------------------------------------------------------------
Received on Thu Aug 25 2005 - 16:31:01 EDT