Re: [xml-dev] MarkMail: now archiving xml-dev

[Jason Hunter <jhunter@acm.org>]

Elliotte Harold wrote:
> Jason Hunter wrote:
> 
>> As you'll see with the chart on the home page, one of our goals with 
>> the site has been to focus heavily on analytics.  We have lots of 
>> graphs and counts.  Every query you write gets its own histogram chart.
>>
> 
> Yes, but it seems to be only the queries you've planned for. What I find 
> lacking in this sort of approach is two-fold:
> 
> 1. The URLs aren't exposed so you can't easily mash things up. It has 
> the classic problem of framed pages, only more so because it's all done 
> with AJAX.

Yes, we do intend to provide a web service style interface.  The 
underpinnings are already there, as is actually necessary in an Ajax 
style application:

http://markmail.org/facets.xqy?q=from:elharo
http://markmail.org/graph.xqy?q=from:elharo
http://markmail.org/message.xqy?id=kpnfvlhadnh3lgkt

The challenge is determining (from real situations) what people want to 
do in a mash-up so that we can properly enable it and support it.  A 
mash-up API isn't something you want to change willy-nilly.  Even the 
famous mash-up sites (Google Maps, Flickr) didn't *launch* with mash-up 
features.  The listened to requests, saw what things people were screen 
scraping, and added the features formally.

If you (or anyone else on the list) have some use cases, send them on 
please.  I have a few ideas, but I need more than my imagination as input.

> 2. The database is not exposed to real XQuery. You can get a lot more 
> out of that database from behind the firewall than we can from in front 
> of it.

Absolutely, we do have the core technology set to do a lot more than 
what we expose.  Many of those things we plan to expose.  Release early 
and often.

> What's presented is a mildly interesting way to ego-surf and kill time, 
> and perhaps marginally better than doing full text search with Google, 

An improvement over Google.  I can live with that.  :)

> but it doesn't really change the game. There may be a lot of power in 
> storing mailing list archives in a native XML database, but that's lost 
> when the database is locked behind a limited, non-XQuery web interface.
> 
> Now if one were to define a way to embed arbitrary XQuery expressions 
> inside a URL and serve those results, then that would be interesting.

Lots of sites would be more interesting if they'd let you execute 
arbitrary code on their server, operating against their database.  I'd 
love it for my credit card statement, my bank statement, my GMail inbox, 
and heck even blogger.com.

I think the reason you *don't* see that is the inherent risk of letting 
someone else run arbitrary code on your server.  What if the user starts 
calculating Pi to 1,000,000,000 digits?  What if they start consuming 
disk or thrashing the disk IO?  When you query against hundreds of gigs 
of content, you don't have to be malicious to mess things up.

One answer is you sandbox the queries.  Easier said than done.  Even 
with Java, where there's a robust security sandbox built right into the 
language, the idea of "mobile agents" hasn't taken off.

Have you seen companies exposing raw SQL to customers?  Do you ever see 
it where there's no commercial relationship involved?

-jh-