mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: svn commit: r791261 - /mina/sandbox/vysper/trunk/src/main/java/org/apache/vysper/xmpp/modules/extension/xep0060_pubsub/handler/PubSubCreateNodeHandler.java
Date Tue, 07 Jul 2009 11:24:13 GMT
Michael Jakl wrote:
> Hi!
> On Tue, Jul 7, 2009 at 12:06, Bernd Fondermann<bf_jak@brainlounge.de> wrote:
>> Michael Jakl wrote:
>>> Currently it should (why not?), but as soon as we allow components to
>>> have different domains it doesn't anymore.
>> That's what I had in mind. What if the pubsub is addressed as
>> pubsub@domain.org, wouldn't this trigger a problem already?
> Very likely. I was planning to address pubsub nodes as domain.tld with a node
> attribute. This is also conform to the disco requests.
> The spec calls pubsub nodes addressable as user@domain.tld "virtual". To
> support addressing using this schema (without big changes), we'd have to
> introduce a virtual user acting as the pubsub service... .
>>> Anyway, the JID for the module should be configured elsewhere, and not
>>> take from the request. I'll fix that too tonight.
>> +1.
>> In a related thought, what do you by the way think about introducing a
>> PubSubConfiguration class where all of the many options possible in
>> pubsub can be collected? The module JID could be one of them.
> The pubsub module doesn't have that many configuration options as far as I can
> see. 

When I read the spec, I just thought at multiple places: Oh, that should
go into a config option! But I never kept a list of those, unfortunately.

> Most of the options are related to LeafNodes, but I'll keep it in mind.
> Concerning the options (together with disco): Somehow I'd like to separate the
> collection of the possible options out of the disco-part (currently all
> supported features have to be put into one class). Something like going through
> all handlers and collection whatever features they support would make many
> things much easier. I think this is exactly what you do with the handlers
> (which handler is responsible for which kind of request).  But that's more or
> less future talk.


> Michael

View raw message