[
Lists Home |
Date Index |
Thread Index
]
On Tuesday 12 February 2002 00:43, Paul Prescod wrote:
> > I'm working on a model for this under the name of Mercury (I have a
> > periodic table fetish); the idea is quite simple at heart. A
> > network-accessible object exposes a set of Interfaces, named with
> > something unique like a URI; each Interface is a set of Methods (Are we
> > object-oriented yet, kids?) with simple string names unique within that
> > Interface (I won't say namespace out loud, but I'm thinking it).
>
> If you start having many of these interfaces, web service combination
> becomes much more difficult. At the very least, if you want the benefits
> of REST, every single interface should have a GET method.
Yes and no. Each interface should, if possible, support a standard human
interface method as well as domain-specified methods. The kind of
architecture I'm looking at is to have a method called 'getUserInterface'
that returns something like a Java class that, on the client, looks at
available UI resources (command streams, GUI/menu systems, etc) through some
kind of abstraction layer so that accessability and varied I/O hardware and
so on are handled by the browser, and presents an interface (hopefully lazily
loading other classes and resources on demand to save from loading icons when
there's only textual I/O available... in Java, this can be done with the HTTP
class loader, I think) and connects back to the domain-specific methods on
the interface it comes from.
So the Security interface would have methods to add and remove access control
list entries, and a getUserInterface that just returns a URL to a standard
public domain class that provides an editing interface to this.
If a request is sent with an interface name of '', the default interface of
the object is accessed. For a document, this would be the Document interface,
not the Metadata or Security or Backup or Management or whatever interface.
For something like a document, the Document interface would be provided,
which has two methods:
1) getContent - returns your XML document or whatever, tagged with a MIME
type 2) getUserInterface - returns a suggested viewer class for that
document, but browsers are free to do their own selection based upon the
MIME type and/or namespace decls in the XML or user overrides or whatever.
So to conclude, I do want lots of interfaces with fine-grained selectability
of particular services of an object, but also high level conventions for
doing basic stuff that are shared wherever practical.
Eg, most things would have a Metadata interface with an "Object[]
getProperties (String wildcard)" method that gets all properties matching a
wildcard name (so you can request individual properties if desired, or use
'.*' to get the lot, or use '^[^#]*#fr$|^[^#]*$' to get all properties in
French or with no #language suffix, or whatever).
Name = "Alaric's Homepage"
Name#fr = "Le Homepage du Alaric" <- Pardon my poor french
Description = .....
LastModified = datetime(2002/02/12 12:46 GMT)
Them properties need a namespace prefix, really, don't they? Perhaps they
should be URIs...
Building standards for those interfaces and methods and conventions and so on
is something that needs to be done, yes, but I don't think it'll be any
harder than establishing the same for XML-over-HTTP.
> Paul Prescod
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software
|
