Jerome Louvel wrote:
In this case that would make sense. And the Restlet framework will support
this in a convenient way at the connector level. You will be able to pass
your "X-Subscribable" and "X-Subscriber" URIs either as call attributes or
as call properties (via a subclass of Call).
Great!
Absolutely, doing some browser specific handling is necessary. The
preferences stored in the Call object contains all the details of HTTP
(multi-preferences and quality levels) so you shouldn't be worried about
losing any bit of info. It's just parsed for you and easily manipulable via
a higher level Java API. But I understand that you need to 'see' the raw
bits in the HTTP header :-)
Yeah, it's a kind of obsessive nuts-and-bolts 'need', but it's paid off
(too) many times in the past.
Agreed. With org.restlet.Call we interact at a higher-level, in a
protocol-neutral way, but must are definitely based on HTTP which is the de
facto standard for REST applications.
Yep. I think trying to become too protocol-neutral too-early can be a
premature optimization -- how much abstraction was added to SOAP so it
could work with SMTP? I think there was a blog recently about this but I
can't remember where I saw it.
Chris
--
Chris Winters ([EMAIL PROTECTED])
Lead Software Developer
Vocollect Healthcare Systems
CONFIDENTIAL, PRIVILEGED COMMUNICATION: This e-mail is private and
intended for the addressee(s) only. It may contain privileged and/or
confidential information. If you have received it in error you are not
authorized to disseminate it in any manner; please delete it and any
copies and reply to the sender that it was misdirected.
