[Developers] Perl API (hi Hayden!)

Hayden Stainsby hds at caffeineconcepts.com
Sun Aug 19 10:00:11 UTC 2007


Kirrily,

I understand where you're coming from regarding wanting to have a  
tighter set of methods for single query submission. I think that's  
exactly what is needed. What I wanted with a Metaweb Perl module was  
a way to access all the base features of Metaweb without actually  
having to write code for HTTP submissions/JSON conversion and  
escaping etc.

My plan for the future (aside from adding much needed transparent  
cursor support), was to create an abstraction layer on top of the  
current module, where a query (or just a guid if you know it) would  
result in a Perl object that you could extract information from,  
preferably as another Perl object. So using your previous example, it  
would be something like:

my $mh = Metaweb->new( blah );
my $films = $mh->fetch_query_results([{
	directed_by => 'Martin Scorsese',
	more blah blah}] );

foreach my $film (@$films)  {
	print $film->value('name') . "\n";

	# but also
	my $actors = $film->objects('staring');
	foreach my $actor (@$actors)  {
		print $actor->value('name') . ' ' . $actor->value 
('date_of_birth') . "\n";
	}
}

This would give programers the ability to traverse trees of Metaweb  
data while writing little to no actual MQL. Kirrily (and everyone  
else), do you think this is the sort of API that you would find  
useful? Does anyone see any problems with working through what will  
become a 2 level API?

My biggest issue with this is purely an implementation issue of how  
to determine which type to look for a property in - especially in  
cases where there are clashing property names.

As per usual feedback is more than welcome. Thanks for everyone's  
input so far.

--
Hayden


On 19 Aug 2007, at 00:56, Kirrily Robert wrote:

> I'm sitting next to Kirsten at BarCampBlock in Palo Alto right now,
> and we were just talking about Perl APIs.  I'm reading the thread that
> starts at http://lists.freebase.com/pipermail/developers/2007- 
> August/000502.html
> and thought I'd give some belated feedback.  Sorry for breaking the
> threading but I only just joined the list last night.
>
> I'd like to draw an analogy to Perl's DBI and Class::DBI modules.
>
> In DBI you work at the level of database handles, statement handles,
> etc, and you write SQL.  This is kinda a pain in the arse because it's
> a bit low-level and also you can't just think in one language.  So
> along came the ORMs (eg. Class::DBI and friends) and made things
> easier and more Perlish, less like writing in SQL and more like
> writing in Perl.
>
> So looking at Hayden's proposed API, which goes something like this:
>
> $handle = Metaweb->new( server / login details here );
> $handle->add_read_query( query here );
> $handle->send_read_envelope;
>
> It's dealing with things like envelopes, but when I'm looking up films
> in Metaweb I'm going to be thinking about films.  So I'd want the
> syntax to reflect that.
>
> Very very roughly, I'd expect something like:
>
> my $metaweb = Metaweb->new( blah blah );
> my @films = $metaweb->query({
>     director => 'Martin Scorcese',
>     blah blah etc
> });
> foreach my $f (@film) {
>    print $f->title();
> }
>
> Now under the hood that might be dealing in envelopes, but I think
> most of the time -- definitely in accordance with the 80/20 rule if
> not moreso -- we're going to be dealing with "here, gimme the results
> of this query" and not want to deal with the under-the-hood stuff.
>
> Shawn seemed to be talking about some similar things back in the  
> earlier thread:
> http://lists.freebase.com/pipermail/developers/2007-August/000510.html
>
> K.
>
> -- 
> Kirrily Robert
> skud at infotrope.net
> http://infotrope.net
> _______________________________________________
> Developers mailing list
> Developers at freebase.com
> http://lists.freebase.com/mailman/listinfo/developers

#!/usr/bin/perl
chop($_=<>);@s=split/ /;foreach$m(@s){if($m=='*'){$z=pop at t;$x=
pop at t;$a=eval"$x$m$z";push at t,$a;}else{push at t,$m;}}print"$a\n";




More information about the Developers mailing list