As I commented in my original email that described how we have successfully taken the single-tier MarkLogic approach for MarkMail, essentially: "your mileage may vary".
I don't dispute that there are a bunch of missing pieces that would be desirable (and in some cases, more than desirable), but the pragmatic question is whether or not the speed-to-market advantages of the single tier approach outweighs the heavier weight approach of involving all the external technologies. This is the fundamental decision that needs to be made. My point was that we have found that over time, lots of customers get to a comfort level with this decision - I think mostly because they get comfortable with all the reasons *to* do it, whereas at the beginning, it's easier to identify all the reasons *not* to do it. For what the server does today, that's just what happens. I chose to make the point, because simply by understanding the road that lots of MarkLogic users have travelled in the past may shorten the time it takes someone else out there who is new to the road to travel it themselves. With respect to your specific comments: - At MarkMail we use squid to deal with the majority of our caching issues (Jason's email comments on this http://markmail.org/message/gx5oa6mwdzlormng) - We use XQuery to transform the XML into XHTML. Leaving aside the XQuery vs. XSLT argument, we find it efficient (both in development, speed-to-market and performance senses) to use what is integrated (XQuery) vs. what is not (XSLT). (See also Jason's email.) - In terms of storing user data in a relational database vs. Mark Logic, we at MarkMail (along with some of our customers) don't see any fundamental limitations to storing it in Mark Logic, and we see lots of advantages. Perhaps it depends on what is in your user data, but I don't agree with the blanket assertion that it's de facto better in an RDBMS. I would agree that if your user data is already somewhere else, that may tip the balance. And I would agree that if your design intent is to create a relational model of your user data, you should probably do that in a relational database. But we haven't found that a relational model is essential to effective representation and use of user data. And we've found lots of benefit to having the user data in the same query context as the app. All that being said, there is absolutely nothing to criticize about the approach you are taking - providing REST web services from ML, and connecting to them via XCC (or HTTP, for that matter). It's proven, it works, and lots of people do it. And it's certainly the easiest way to integrate into your existing environment. In terms of specifics about MarkLogic Server 4.0, we generally don't comment about release functionality in advance of the release. The one venue where we sometimes do this is at our User Conference, which we did this year, under general cone of silence with the attendees. Don't get me wrong, I agree that for these purposes the server can be better than it is today. That's not special; we think that about almost every aspect of the server, which is how we make it better with every release; what is different is that it's a bit easier to identify some of the pieces in this area than it is in others. And yes, I expect some aspects of this will be better in MarkLogic Server 4.0, so it will be another step in the right direction. And no, I don't expect that the journey will not be complete, because it never is. Cheers ian > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Whitby, Rob, CMG > Sent: Thursday, August 28, 2008 6:44 AM > To: General Mark Logic Developer Discussion > Subject: RE: [MarkLogic Dev General] Quirks of generating > xhtml with xquery > > I looked at writing web apps in pure XQuery, but found some > big limitations. ML's web server is lacking in some key > features like caching. XQY is not great at transforming XML > into XHTML (why no XSLT engine?!). The single-tier > architecture may be ok for rapid development of demos, but > doesn't suit larger applications. For example a lot of "non > content" data is best stored in a relational database (eg user > data) but ML can't connect to anything other than by http (afaik?). > > I decided on using providing REST Web Services from ML, and > connecting to them by XCC. > > I'd love for ML 4.0 to address some of these issues - is > there somewhere I can read details about the changes? > > Rob > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Ian Small > Sent: 27 August 2008 23:44 > To: General Mark Logic Developer Discussion > Subject: RE: [MarkLogic Dev General] Quirks of generating > xhtml with xquery > > In terms of the merits of creating an entire website by > generating xhtml out of xquery, we do it all the time here at > Mark Logic, with markmail.org being a marquee example of what > can be done. > > Our fastest-moving customers do it this way when they can, > because they can build websites on top of their content sets > faster this way than any other. (Often, MarkLogic users > don't start out this way, because they are looking for the > least disruptive way to introduce MarkLogic into their > development environments. By the time a couple of years > pass, they've figured out that the way they develop all their > internal proofs-of-concept could be the way they develop > applications.) A few folks take a bolder step, embracing the > full "X" stack: XML -> XQuery > -> XHTML from the start. > > If you try it yourself, you'll eventually find some web site > management and programming techniques that you can't quite > get your hands on directly. Based on what we covered at the > user conference, MarkLogic Server 4.0 is expected to close a > number of those gaps. > > markmail.org, which is running on MarkLogic Server 3.2, gets > everything it needs out of the combination of a slick > hardware load balancer, squid (which we use for reverse > proxy), and MarkLogic Server dynamically generating > Javascript-enhanced XHTML. There's nothing else between you > and the content. If you'd like to learn a little more about > the approach, this presentation is a decent start: > http://markmail.blogspot.com/2007/12/keynoting-xml-2007.html > > ian > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Eric > > Palmitesta > > Sent: Wednesday, August 27, 2008 2:54 PM > > To: ML Developer Mailing List > > Subject: [MarkLogic Dev General] Quirks of generating xhtml with > > xquery > > > > Aaron and I discussed this briefly at the training seminar, but I'd > > like to get a sense of what other developers are doing to > get around > > the quirks of generating xhtml with xquery (rather than a java > > servlet/jsp based website which pulls records from MarkLogic via > > XDBC/XCC. > > > > One such quirk: Childless elements with no internal nodes and an > > explicit closing tag are automatically folded into elements with no > > closing tag. <div></div>, which is valid xhtml, will > become <div /> > > after being processed by MarkLogic (breaks visual representation). > > Some better examples are <script ...></script> and > > <textarea></textarea>, which are expected to contain no > internal nodes > > > in xhtml. > > > > I've taken to writing things like > > > > <script ... >{" "}</script> > > > > or > > > > <textarea> </textarea> > > > > which successfully preserves the explicit closing tag, > keeping xhtml > > happy. Is there a more elegant way to do this? > > > > Are there other banana-peels I should watch out for when generating > > xhtml with xquery? Is creating an entire website by > generating xhtml > > with xquery generally frowned upon, or accepted? > Admittedly, it seems > > > less flexible than a <web > > language>-based site, however the xdmp namespace seems to > > provide sufficient functionality, and transforming xml data > into xhtml > > > is incredibly easy with xquery. > > > > Cheers, > > > > Eric > > > > > > PS > > My vocabulary might be incorrect regarding words like 'tag' > > and 'node', please correct me if necessary. > > > > PPS > > I can see the archives at > > http://xqzone.marklogic.com/pipermail/general/ > > but are they searchable? I have a feeling newcomers such as myself > > will be prone to asking questions which have already been > discussed at > > > length. > > _______________________________________________ > > General mailing list > > [email protected] > > http://xqzone.com/mailman/listinfo/general > > > _______________________________________________ > General mailing list > [email protected] > http://xqzone.com/mailman/listinfo/general > _______________________________________________ > General mailing list > [email protected] > http://xqzone.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
