> Otherwise clients may use any names with Entity Capabilites (ext
> attribute). Therefore a same name could mean something
different for
> each active resource of my roster, which would require an IQ
for each.
> Why not define a standard name for each XEP like "xep-0167", or
> shorter "0167" for previously used "jingle-audio"? Maybe a
prefix for
> private extensions?
I *think* we don't need the appnames (just one more mapping for
clients
to remember) and can use XML namespaces instead. If not, we can
always
add the appnames back in. I was just trying to simplify things.
You are right, from one viewpoint ;) Appnames are redundant, and
would
increase the registrar's workload.
OK. I'm all in favor of making life easier for coders.
What do others think?
I think we already had this conversation on this list several months
ago, and I think I'm still pretty opposed to hardcoding the meanings
of ext strings into clients. If we do it, fine, I'll recode, but I
dislike it now for all the same reasons I disliked it several months
ago. The main one being that, like resources, I do not feel ext
strings should have an implied semantic meaning. They are a code
identifier, not necessarily a bit of human-readable data.
Every other objection aside, I still fail to see that maintaining a
hardcoded table of ext string meanings is 'easier' for me as a client
dev. Doubly so since if a client defines any customized extensions
I /still/ have to probe node#ext to get those *anyway*; it doesn't
make it 'easier,' it just means I have to do everything I do now,
but /also/ maintain a table of hardcoded ext values and use those
instead of probing them. Basically, pre-filling my ext cache and
allowing special case situations where the 'node' portion of
'node#ext' is meaningless. Which is doable, but does make for extra
work to do 'right.'
I also still feel, as before, that rewriting an existing, functional
and widely deployed XEP is not the best use of our time when we still
have situations such as two incompatible file transfer protocols
floating around. That may be just me, though. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
