By the way, apart from the point mentioned in this thread, I think
the current app spec is very good, and a great step forward on what
has existed before. I am sorry if my thread started off with the
wrong tone. It is difficult sometimes to get tone right.
On 6 Jul 2006, at 06:23, Alex Milowski wrote:
Henry Story wrote:
So here goes: the service document contains nearly no information.
Why is it needed? Why have a whole mime type for what is pretty
much an empty document.
In my service, where I have a hierarchy of collections and lots of
collections, the service introspect document is quite full of pointy
brackets.
Could you point me to this? I'd like to see the whole implementation
from beginning to end. Ie. The user starts somewhere (a web page?)
gets to the introspection document and then does something with it.
I have no doubt that individual <service> documents can contain a lot
of information. The problem is: it is mostly the same type of
information: a url pointing to a feed with some info on what mime
types that feed accepts. If that is all the info there is in there,
then it seems to me a little expensive to create a whole new mime
type for such a document. Especially as there seems to be an obvious
location to place this information: the feed itself.
Besides... as service provider might want you to start at one
point (the introspection URL) and then redirect you to the
server for today's work.
I would have rather had the workspace be a feed so that each
collection had an entry where I could edit the metadata associated
with the feed. ...but that is a different thread all together.
Ok. I think we are not the only ones to think this on this list.
Clearly there seems to be something that could be done in a lot more
elegant manner here.
But those that have tried to put forward new ideas in this area have
always been shot down on technicalities. This is why I think one has
to start with something more forceful: namely that we have
unnecessary complexity in the protocol as currently presented, with
commensurate reduction in functionality (unnecessary complexity as we
know from the soap experience is not a good thing).
Henry Story
Home page: http://bblfish.net/
Sun Blog: http://blogs.sun.com/bblfish/
--Alex Milowski
