Re: MarkMail: now archiving xml-dev
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-
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format