[Standards-JIG] Component protocol : JEP 114

Mridul Muralidharan mridul at sun.com
Thu May 11 20:02:45 UTC 2006


Hi,

  Yes , I meant the component which connects to the server , not the 
enduser clients :-) which ofcourse use disco.

In our api , the way dev obtains his client session and component 
session is almost same - just creds are different and initial jid handling.
The component creds are preconfigured at the server side and mirror'ed 
at the component client in question , but other than this there is no 
coupling between both.
That is , a component could be brought down in one node and brought up 
in another , or the server could be reconfigured to change its domain , etc.
Only dependency is that the component jid and password remain valid and 
same on both ends.

Hence , the component (connecting client side) will need a way to find 
out the server's domain (for disco primarily I think , but maybe for 
other requests as well).
Any suggestions other than expecting this also to be hardcoded on the 
component side ?
In our current implementation , the server returns its jid as the 'from' 
in the stream response ...
Since it was clarified that this was wrong , I want to find out how we 
can solve this and obtain the server jid at the component client side.

Thanks and Regards,
Mridul

Peter Saint-Andre wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Mridul Muralidharan wrote:
>  
>
>>Hi Peter,
>>
>>Please see inline.
>>Regards,
>>Mridul
>>
>>Peter Saint-Andre wrote:
>>
>>Mridul Muralidharan wrote:
>> 
>>
>>    
>>
>>>>>Hi,
>>>>>
>>>>>It would be great if someone could clarify this for us.
>>>>>In section 3 (Protocol flow) of the JEP , it is specified that the 'to'
>>>>>while opening the stream should be the component jid , but nothing is
>>>>>mentioned about the 'from' for the response from the server.
>>>>>The example gives the impression that the 'from' should be the component
>>>>>jid itself , while xmpp specifies that it should be the server domain.
>>>>>Which of this is correct ?
>>>>>  
>>>>>          
>>>>>
>>In the stream header from the server to the component, the 'from'
>>attribute is set to the component JID. I realize this is kind of
>>backwards from the XMPP perspective, but in large measure JEP-0114
>>documents existing practices from a long time ago.
>>
>>You can think of it this way: the component doesn't have a JID, it's
>>just some entity out there. It "wants" to be plays.shakespeare.lit or
>>whatever, so when it connects to the server it puts that component JID
>>in the 'to' address.
>> 
>>
>>
>>    
>>
>>>Ok , thanks for clarifying this - was not clear from the spec what the
>>>'from' in the response should be.
>>>      
>>>
>> 
>>
>>    
>>
>>>>>Finding out the (default) domain of the server is something which would
>>>>>be necessary for the component client.
>>>>>  
>>>>>          
>>>>>
>>Are you talking about virtual domains? So let's say the server hosts
>>both shakespeare.lit and hamlet.lit. Your question is: "how does the
>>component know which domains the server hosts, and therefore how does it
>>know what component JID to request?" Correct?
>> 
>>
>>
>>    
>>
>>>As of now , we configure the component jid at the client side -
>>>hardcoded into some property file for instance.
>>>Problem is that , if the client does not know which is the server domain
>>>, it will not be able to issue requests for the server as such.
>>>      
>>>
>
>Hardcoding = bad
>
>Why can't your client send a service discovery request to its server
>after it connects and then figure out what components are available?
>
>Or when you say "client" do you actually mean "component"?
>
>Usually components are pre-configured by a sysadmin to be located at a
>particular hostname (e.g., conference.jabber.org) rather than having
>dynamically-assigned hostnames, but perhaps I'm missing something.
>
>Peter
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFEY3iENF1RSzyt3NURAspwAJwO0Ym9tXDJ+tchKdi7ovxEMCZpGACgnmvP
>zNUuMpVUdLazHq7oJMYMS2Q=
>=B+xz
>-----END PGP SIGNATURE-----
>  
>




More information about the Standards mailing list