Re: Protobuf, protocolbuffer
A while back I wrote a Restlet Representation that could be used for wrapping a protobuf. The code is in the issue tracker, but i never got around to cleaning it up such that it could be checked in. Unfortunately my current job makes contributing to Restlet (or any open source project) a bit painful, so I probably won't be able to finish the work. Dave On Wed, Apr 21, 2010 at 3:26 AM, Alexander J. Perez Tchernov xas...@gmail.com wrote: I suppose it can be great if to choose protobuf+gzip/protobuf+deflate (*) media-type. Some links as well ... *Protobuf* http://code.google.com/p/protobuf-gwt/ http://code.google.com/p/protobuf-js/ http://code.google.com/p/google-web-toolkit/issues/detail?id=2649 * Rest* http://code.google.com/p/gwt-rest/ http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/144-restlet.html *Benchmarking* http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking (*) http://www.qos.ch/pipermail/logback-dev/2009-March/003889.html On Wed, Apr 21, 2010 at 12:58 PM, Xavier M. xavier.meh...@gmail.comwrote: Hello, I would like to know if it is intended to use protobuf/protocolbuffer for exchanging compressed structured data over the net through Rest. http://code.google.com/p/protobuf/ http://code.google.com/intl/fr/apis/protocolbuffers/docs/overview.html regards Xavier -- Best regards, ~ Xasima ~ -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592800
Re: XML format in ATOM content element
Not sure about your formatting problem, but I thought i'd mention that
you need to add a namespace declaration (at the minimum use the
default namespace) on the XML within your atom:content element,
otherwise an XML processor is going to assume that your XML is in the
Atom namespace and many processors will fail. That said, why not use a
standard dialect such as hCard in xhtml to represent your contact
objects?
dave
On Mon, Dec 7, 2009 at 10:24 AM, Rob Lincourt rob.linco...@gmail.com wrote:
Hi,
I am trying to use the Restlet ATOM extension and I cannot figure out why
I am losing the formatting of my content element in the Atom document I am
creating. Here is a piece of code from my class that extends ServerResource:
public Representation getAtomFeed() throws IOException {
Feed f = new Feed();
MapString, String attrs;
f.setTitle(new Text(MediaType.TEXT_PLAIN, Feed Title));
f.setId(some identifier);
Person p = new Person();
p.setName(me);
f.getAuthors().add(p);
Generator gen = new Generator();
gen.setName(RESTlet);
gen.setUri(new Reference(http://www.restlet.org;));
gen.setVersion(2.0M6);
f.setGenerator(gen);
f.setUpdated(new Date());
//Add feed links
//...
//Perform query that returns a map of strings.
attrs = something.getAttributes(someValue);
Entry entry = new Entry();
entry.setUpdated(new Date());
entry.setId(identifier);
Content c = new Content();
c.setToEncode(false);
c.setInlineContent(new SaxRepresentation(MediaType.APPLICATION_XML) {
�...@override
public void write(XmlWriter writer) {
for(Map.EntryString, String e : attrs.entrySet()){
try {
writer.dataElement(e.getKey(), e.getValue() == null ?
: e.getValue());
} catch (SAXException e1) {
e1.printStackTrace();
}
}
}
});
entry.setContent(c);
//Add entry links
//...
f.getEntries().add(entry);
return f;
}
Here is the ATOM feed that this code creates:
?xml version=1.0 standalone='yes'?
feed xmlns=http://www.w3.org/2005/Atom;
author
nameme/name
/author
generator uri=http://www.restlet.org; version=2.0M6RESTlet/generator
idsome identifier/id
title type=textFeed Title/title
updated2009-12-07T13:03:04.79Z/updated
entry
content type=application/xmlDisplayNameJohn Smith MD/DisplayName
FirstNameJohn/FirstName
LastNameSmith/LastName
SuffixMD/Suffix
/content
identry identifier/id
updated2009-12-07T13:03:07.65Z/updated
/entry
/feed
Is there a way to correct this format issue or I am completely off base with
my resource code. Any help is appreciated.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2428073
Bug with getClientInfo().getPreferredVariant()
The HTTP spec section 14.1 states: If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response. So I'm wondering if from within the handle() method in a Restlet if the following code should return null: request.getClientInfo().getPreferredVariant(variants, this.getApplication().getMetadataService()); if a client's request does not include one of the variants in the variants List, so that a server can detect the situation and return 406. Right now it seems to return the first variant in the variant list. Thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2423188
Re: Newbie question about passing JSON object in a get request
If you're passing the JSON object as part of the URL it must be URL encoded.
Dave
On Sat, Nov 21, 2009 at 7:51 PM, Steven Headley shead...@swbell.net wrote:
I am trying to pass a JSON object in a restlet client get request as follows:
final Client client = new Client(Protocol.HTTP);
Log.info( json = +json);
client.get(http://localhost:8080/greet+/+json, new Callback() {
�...@override
public void
onEvent(Request request, Response response) {
This get request gives me the following error:
2009-11-21 22:49:08,921 [FATAL] Uncaught Exception:
java.lang.IllegalArgumentException:
Invalid character detected in URI reference at index '28': {
any help would be appreciated.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2422957
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2423232
Re: GET and POST - Semantics vs. Function
Hi Andrew, It might be more useful if you could supply a more detailed example that is causing you headaches. Really the difference between POST and GET is idempotence. GET operations must be idempotent, not having side effects, while POST operations may have side effects as defined by the server. A good rule of thumb is that if a request returns data but doesn't change the state of the server, than GET should be used as it allows for sane client/intermediary caching. On Sat, Sep 12, 2009 at 12:21 PM, Schley Andrew Kutz sak...@gmail.com wrote: I'm faced with a dilemma. I'm trying to be a good RFC consumer and stick with the true purpose of GET and POST (see http://www.cs.tut.fi/~jkorpela/forms/methods.html for a good discussion on the history of these two HTTP verbs). Plainly put, GET is for retrieving data and POST is for creating data. However, the problem lies in the fact that their purpose and their data encoding mechanism are mutually exclusive. GET requests encode data in the URL and POST requests encode data into the form. However, it is not always desirable to issue a GET request with URL-encoded data (login information for example), not is it always desirable to POST data with a form (sometimes a query string will do). I actually disagree with this statement. Using GET to pass login parameters is fine, and in some cases preferable (particularly as it relates to client caching). If you're concerned about security, you should encrypt such requests using SSL (you really should do this regardless of the method used in this case). Also the URI RFC doesn't require that URI parameters be form encoded. You could as easily pass JSON, XML, etc. in the query string as long as it is properly escaped. Form encoding for these parameters is typically chosen as a pragmatic decision due to HTML. Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2394479
Re: Guidance on Atom/APP in Restlet
On Tue, Jul 21, 2009 at 6:08 AM, Tim Peierlst...@peierls.net wrote: Hmm, the wind is going out of my sails. I started by recognizing that AtomPub seemed to be a natural fit for my domain, and now I'm looking at JSON/serialized beans and optional plain Atom feeds. (Optional in the sense that my main applications wouldn't need them, because they'd be happily talking JSON.) Interestingly enough, when work first began on the AtomPub spec, there were some in the working group who were in favor of making the spec representation agnostic [*]. Even with its concentration on Atom as its representational format, the App spec for managing collections provides a pretty clear outline of how to use HTTP effectively for managing datasets. [*] One of the AtomPub spec authors clued me in to this a few months ago. Anybody have anything encouraging to say about why I shouldn't just stick with my existing DWR application? (www.directwebremoting.org) --tim I haven't used DWR in probably 3 years so I'm sure some stuff has changed but let me enumerate my reasons for preferring a REST approach: 1) REST approach works with the web, RPC works against it. When you design your service API Restfully you get all the built in benefits of HTTP such as: cache support, security, scalability, wide client support, etc. This approach is proven. When using DWR you get none of these. DWR must push all requests over POST to ensure that no cache server accidentally caches a result thus breaking your app. Conversely when using DWR you can't leverage internet caching architecture that can help offload your servers. Furthermore, a restfully linked set of resources that support con-neg can support multiple representational types (such as HTML), thus your API is not just an API but also a static HTML website that can be indexed by search engines, and allows for a nice debugging interface in a browser. 2) Strongly defined server interface that is implementation agnostic. When using DWR, you essentially are exposing your server's Java methods and tying your client to that implementation. You can't replace your Java implementation with one in Ruby/C#/fill in the blank language, later. With the REST approach you are essentially defining an implementation neutral wire protocol. 3) Strong client/server separation. When using HTTP as your protocol, you're forced to acknowledge in your client code that you are accessing a remote resource and take this into account. One of the major flaws with RPC systems has been the attempt to give remote resources the appearance of being local, which just doesn't work well in practice. 4) Multiple client support. DWR only allows you to build your client in JavaScript (well at least in a well defined way). However, what happens when your service takes off and you want to support an iPhone Apps, Android Apps, Desktop widgets, etc. A well defined REST service may be reused across devices, because it defines a data model with well understood semantics. That said, from a software engineering perspective you need to look at your intended goals for your application and make a sane cost/benefit analysis. Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2373212
Re: Receive a multipart HTTP response
On Fri, Jul 17, 2009 at 12:02 PM, Evgeny Shepelyukeshepel...@gmail.com wrote: 2. we need to read long time multipart HTTP response item by item 3. i think FileUpload extension will work only after complete read of input stream. but in our case the request is never finished and the items should be read from stream only when available. Sounds like you want to implement a comet client. I'm pretty sure you could achieve this using the apache fileupload streaming API. See http://commons.apache.org/fileupload/streaming.html. You would probably have to implement a callback api to asynchronously return data to your main application thread as it arrives. That said if you're outside of a browser have you considered using XMPP which as a protocol is much better suited for the purpose? dav -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372649
Re: Receive a multipart HTTP response
Check out org.restlet.ext.fileupload. Its a representation wrapper around apache file upload that will allow you to parse multipart uploads. dave On Fri, Jul 17, 2009 at 8:02 AM, Evgeny Shepelyukeshepel...@gmail.com wrote: Hello We're about to develop application that should read data from video camera. Data from camera is sent via HTTP as single multipart _response_. My question is ift convenient and possible to use restlet to read such kind of data. Is there any possibilities not to manually read boundaries header from input stream but rather use some high-level api. Smth like reponse.getNextPart() - this return bytes of next chunk from stream. Referring to this article at StackOverflow/ http://stackoverflow.com/questions/419850/java-receive-a-multipart-http-response -- Regards, Evgeny Shepelyuk -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372092 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372127
Re: REST in mobiles
You can definitely run a web server on your phone. The bigger issue you will encounter is that your mobile device almost definitely doesn't have a routable IP and is most likely behind several NATs and FWs. What are you trying to do? dave On Fri, Jul 17, 2009 at 4:14 AM, feda abdulo...@hotmail.com wrote: I am new to RESTFul web services and Iwould like to know if itis possible implementing RESTFul web services on mobile devices acting as server and consumed from other desktop or mobile devices. Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372023 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372128
Re: Guidance on Atom/APP in Restlet
One way I've worked with Atom services within Restlet is to use freemarker templates to generate atom representations and use an XML parser to parse entity bodies of APP POST/PUT requests. This allows me to extract the data I'm interested in without pulling the whole Atom tree into memory as Rome would. A nice side effect of this design is that my resources support con-neg and can also return and process hAtom micro-formatted HTML and JSON (both generated using freemarker as well). One more note, Atom XML is great to use when you need to support generic APP clients, but if you control both the client and server I'd seriously consider using JSON (while also supporting Atom). JSON tends to push fewer bytes across the wire is infinitely easier to parse in a browser (I'm not an XML hater, but when you need to support IE 6). Dave On Fri, Jul 17, 2009 at 2:00 PM, Tim Peierlst...@peierls.net wrote: Thanks, Stephen, this is very helpful. --tim On Fri, Jul 17, 2009 at 3:01 PM, Stephen Groucutt stephen.grouc...@gmail.com wrote: I'll qualify this by saying that I know of plans to use APP in enterprise applications, but I haven't ever actually seen anything in the enterprise. There's a good presentation on APP's capabilities in non-trivial environments over at http://qconsf.com/sf2007/presentation/Building+your+next+service+with+the+Atom+Publishing+Protocol that you might find helpful if you haven't already read it. To my mind, the thing APP really has going for it in terms of how it applies to the REST world is that it is a media type that allows for the fulfillment of the hypermedia as the engine of application state part of Dr. Fielding's thesis. You can use the feeds, the links in the feeds, and some microformats you can develop specifically for your program domain, to develop APIs. Links can send your clients to the next step of your workflows, if the clients understand your microformats. If you google around for restbucks, you should find a good presentation on that kind of stuff. In theory, it sounds great (but again, I haven't seen it done myself). As to what extensions are best, I was working on Atom stuff back around 1.2 milestone 4 or so, and at that time I found it easiest to use ROME to offer up feed representations instead of the Restlet Atom extension, so I can't say much about what would work best now. On Fri, Jul 17, 2009 at 2:32 PM, Tim Peierls t...@peierls.net wrote: Some rambling newbie Restlet design questions: Background: I'm in the preliminary stages of a ground-up redesign of an existing non-Restlet application. I'm (naturally) convinced that Restlet is the way to go for this redesign, and I'm pretty sure I want the UI to be GWT-based. So far so good ... GWT-Restlet is alive and well. (And I'll get cracking on a Restlet-Guice extension before too long, or not, depending on how you define too.) My analysis of the existing application keeps leading me to the Atom Publishing Protocol, because the key elements of that application feel like collections of publishable/updatable resources (and collections of such collections). It doesn't fit the canonical examples of APP, however, which leads to my first questions: Does anyone know of APP being used successfully outside of the usual document/news item examples that everyone uses to explain it? If so, what criteria would you use to determine whether APP is really appropriate to my resource design? I'm sort of hoping the answer is a resounding yes to this, in which case my second question is: If I want to design my application around APP but I don't intend to use a file-based storage system like eXist, what does Atomojo have for me that the Restlet Atom extension doesn't? Is there something else that I should know about? --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372172
Re: Licensing question
Its probably worth mentioning that javax.xml.stream is part of the core Java SDK in version 1.6. I suppose that it is included in the Restlet distribution only to support building on java 1.5. If you're concerned you could distro your application against version 1.6 of Java. Also I doubt that javax.xml.stream is required for any the core Restlet classes. dave On Mon, Jul 13, 2009 at 12:29 PM, Jennifer Carluccijoff...@us.ibm.com wrote: As part of clearing Restlet v1.4 through our legal team to include it in our product, we did code scans of the javax.xml.stream package. The license.txt shows that the bundle is licensed under CDDL, but the code scans show that the source contains the BEA license. Does the CDDL license that's found in the bundle override the BEA license that's found in the source? Thanks, Jennifer Carlucci -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2371326
Re: how to unsubcribe
Log into your tigris account at restlet.tigris.org. In the discussions section, there is a link to manage your subscriptions. Pretty self explanatory from there. dave On Tue, Jul 14, 2009 at 11:41 AM, ilangoilango...@yahoo.com wrote: Hi I want to unsubscribe from this group. How would I do that? thanks ilango --- On Mon, 6/1/09, Jerome Louvel jerome.lou...@noelios.com wrote: From: Jerome Louvel jerome.lou...@noelios.com Subject: RE: get servletContext on GAE? To: discuss@restlet.tigris.org Date: Monday, June 1, 2009, 4:33 AM Hi Zsolt, Did you have a look at Restlet extension for Velocity? It doesn't need a ServletContext. Otherwise, I've just changed the ServerServlet in SVN trunk to copy the ServletContext into a special org.restlet.ext.servlet.ServletContext attribute of both the Component's context and the Application's context. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Zsolt Czinkos [mailto:czin...@gmail.com] Envoyé : vendredi 22 mai 2009 00:49 À : discuss@restlet.tigris.org Objet : get servletContext on GAE? Hello Restlet 1.2 snapshot on GAE. Is it possible to get servletcontext on gae? How? I'd like to try velocity, and need ServletContext for init Velocity engine. Thanks in advance, it must be a trivial question... zsolt -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23526 94 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2357406 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2371327
Re: Distributed Observer Pattern
You might want to check out the following IETF draft that proposes a standard for doing this with SIP. You'd probably want to follow at least the style of this proposal in your implementation. http://www.ietf.org/internet-drafts/draft-roach-sip-http-subscribe-01.txt dave On Mon, Apr 20, 2009 at 8:03 AM, Jurrie Overgoor jur...@stillus.nl wrote: Hello everyone, I'd like to implement something based on the Distributed Observer Pattern as described by Duncan Cragg on http://duncan-cragg.org/blog/post/distributed-observer-pattern-rest-dialogues/ When a client GETs a resource, I like it to send an extra header saying it wants to receive a POST when the resource is updated. When the resource is updated, it POSTs to the clients URL and removes it from the list of clients to notify. The client then fetches the resource again with a GET (updating caches in the process), and subscribes again. In the resource, I need to store the URL of the clients that it needs to call when it is updated. But in Restlet, resources are created every request. Where should I store the list of URLs? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1825957 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1847272
Re: ServerResource conditional mode
Have you considered that having a generic server resource might be a bit to simplistic or not granular enough? I guess from my point of view the resource class is really the implementation of the gritty protocol details of your application. I'm wondering if at least in addition to ServerResource, if resources such as AtomPubCollectionResource and AtomPubEntryResource would be useful to implementors who want to use standard RESTful protocols without needing to dig into the details. thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1634241
Re: Integrating WADL and Spring
It would be nice if you could allow more fine grain configuration support via WADL, including adding Guards to resources, configuring what methods and variants a resource supports via WADL etc. I added some technical suggestions in the bug itself. dave On Mon, Mar 9, 2009 at 10:02 AM, Jerome Louvel jerome.lou...@noelios.com wrote: Hi all, This is a good idea indeed. I've made a first step by updating WadlApplication to make it easy to customize the way resources are created based on the WADL resource descriptor, as suggested by Rhett. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Rhett Sutphin [mailto:rh...@detailedbalance.net] Envoyé : dimanche 8 mars 2009 03:07 À : discuss@restlet.tigris.org Objet : Re: Integrating WADL and Spring Hi David, On Mar 6, 2009, at 4:10 PM, David Bordoley wrote: On Fri, Mar 6, 2009 at 11:32 AM, Rhett Sutphin rh...@detailedbalance.net wrote: This would be an RFE (at least, I'm not aware of any way to get it to work currently). I'm curious about how you would tie the resources in your application context to the WADL. Would you add a custom attribute for the spring bean id? Is there a WADL feature which would help with this? I'm not that familiar with it. Rhett Hi, The current way WADL works in Restlet is to require implementors to specify the class of the resource you want to map a WADL resource to using the resource's id attribute. You then pass the the WADL xml as a constructor argument to a WadlComponent or WadlApplication. You can see an example of this in org.restlet.test.YahooSearch.wadl (omitting the details in the example below): application resources base=http://api.search.yahoo.com/NewsSearchService/V1/; resource id=org.restlet.test.NewsSearchResource path=newsSearch /resource /resources /application It would be cool if you could do something similar but instead of passing a Resource class (and be stuck using the default constructor etc.), instead use a Spring Bean id as the resource id in WADL, and have restlet use spring to wire all the resources together, thus getting all the benefits of IOC, while also being able to more explicitly state your resource interface in a standard method. Anyway i can open an RFE if necessary, but I wanted to ask on the list first. This is a good idea. I think the implementation might be more generic than just spring support, so I went ahead and entered the RFE against the WADL component: http://restlet.tigris.org/issues/show_bug.cgi?id=756 Thanks, Rhett -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=12864 20 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1297634 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1298256
Re: File upload - as stream
Apache File Upload supports a stream API. (see http://commons.apache.org/fileupload/streaming.html) You should be able to use it with RestletFileUpload. dave On Sun, Mar 8, 2009 at 10:41 AM, Matt Rutherford ima...@gmail.com wrote: Hi. Is there a way to receive a file element from an html form without storing it to disk? I will be storing the file directly into a DB so no need to have it on disk anywhere. Would be nice to just stream bytes to the LargeObject.write() Postgres JDBC method. Sorry if this is a silly question, I'm a (enthusiastic) beginner with this stuff. Any guidance much appreciated. Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1298336
Integrating WADL and Spring
Hi All, I've been playing around with Restlet for some projects I'm working on and have really enjoyed the platform. I'm wondering if there is a way to define your service in a WADL document but still use Spring to configure all your applications Resources, etc. In the abstract what I would like to do is is define a WADL but instead of using ID's which map to Java classes, map them to Spring bean ids, essentially use WADL as a replacement for SpringRouter. Any suggestions? Is this an RFE? Thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1278554
Re: Integrating WADL and Spring
On Fri, Mar 6, 2009 at 11:32 AM, Rhett Sutphin rh...@detailedbalance.net wrote: This would be an RFE (at least, I'm not aware of any way to get it to work currently). I'm curious about how you would tie the resources in your application context to the WADL. Would you add a custom attribute for the spring bean id? Is there a WADL feature which would help with this? I'm not that familiar with it. Rhett Hi, The current way WADL works in Restlet is to require implementors to specify the class of the resource you want to map a WADL resource to using the resource's id attribute. You then pass the the WADL xml as a constructor argument to a WadlComponent or WadlApplication. You can see an example of this in org.restlet.test.YahooSearch.wadl (omitting the details in the example below): application resources base=http://api.search.yahoo.com/NewsSearchService/V1/; resource id=org.restlet.test.NewsSearchResource path=newsSearch /resource /resources /application It would be cool if you could do something similar but instead of passing a Resource class (and be stuck using the default constructor etc.), instead use a Spring Bean id as the resource id in WADL, and have restlet use spring to wire all the resources together, thus getting all the benefits of IOC, while also being able to more explicitly state your resource interface in a standard method. Anyway i can open an RFE if necessary, but I wanted to ask on the list first. thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1279214
