[sip-comm-dev] XCAP impl some questions


#1

Hi,
I'm going to implement XCAP in Sip Communicator, for now I have some
questions:
1. Should we support partial operation with the contacts (see examples in
http://tools.ietf.org/html/rfc4825#page-56) ?
2. Should we support watcher list (http://www.ietf.org/rfc/rfc3857.txt) ?
3. How XCAP layer should look like?
It has to be abstract as much as possible (it will provides all
functionality through interfaces and events, will contain all validation,
updating logic and so on)
or it has only get/set/delete operation with the server and all other logic
should situated on the Sip Communicator side (i.e XCAPClient operates only
with the server <-> ServerStoredContactListSipImpl has all validation logic,
it knows about XCAP structure and decides when and how to update server
state) ?
Any comments/thoughts are very welcome.
Thanks, Grigorii


#2

Hi Grigorii,

first of all congratulations for your succesful application.

Regading your question:

1) I'll check 4285 again to see what are the pros/cons of partial
   operation and if it is necessary to have this in a first step.

2) need to make up my mind first :slight_smile:

3) I'm not quite sure if I understand your question correctly :slight_smile: .
   IMHO it would make sense to keep the interface to the XCAP server
   as slimm as possible and implement mot of the logic into SC. This
   way SC does not depend on server functions (we probably need to
   support many of them operated by many operators). Of course, we
   need to go step by step when implementing the XCAP Contact list
   logic in SC, ot everything is required in a first step.

Grigorii, please do not hestitat to contact me with private mails to
discuss topics that are not yet ready for the global developer's list.

Regards,
Werner

···

Am 30.04.2010 15:34, schrieb Grigorii Balutsel:

Hi,
I'm going to implement XCAP in Sip Communicator, for now I have some
questions:
1. Should we support partial operation with the contacts (see examples in
http://tools.ietf.org/html/rfc4825#page-56) ?
2. Should we support watcher list (http://www.ietf.org/rfc/rfc3857.txt) ?
3. How XCAP layer should look like?
It has to be abstract as much as possible (it will provides all
functionality through interfaces and events, will contain all validation,
updating logic and so on)
or it has only get/set/delete operation with the server and all other logic
should situated on the Sip Communicator side (i.e XCAPClient operates only
with the server <-> ServerStoredContactListSipImpl has all validation logic,
it knows about XCAP structure and decides when and how to update server
state) ?
Any comments/thoughts are very welcome.
Thanks, Grigorii

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hey folks,

На 01.05.10 12:22, Werner Dittmann написа:

1) I'll check 4285 again to see what are the pros/cons of partial
   operation and if it is necessary to have this in a first step.

2) need to make up my mind first :slight_smile:

Yes, we should probably discuss these. At the end of the day, what we
really need here is:

1. Make our SIP protocol provider retrieve contacts from the server just
as most protocol would.
2. Make sure that what we implement works with popular deployments and
server implementations of XCAP but only for the contact list storage use
case (and I don't think there's an awful lot of them).

Supporting authorization policies is therefore also an important part,
although probably not the one with the highest priority. Could keep it
for after we have a first working implementation.

3. How XCAP layer should look like?
It has to be abstract as much as possible (it will provides all
functionality through interfaces and events, will contain all validation,
updating logic and so on)

Well that's kind of the purpose of our operation sets so I don't think
we'd need to introduce another abstraction layer here. This doesn't mean
you would have to dump all the code in ServerStoredContactListSipImpl,
of course.

You could still add an xcap package in impl.protocol.sip and implement
utility classes in there but they should be built for
ServerStoredContactListSipImpl rather than a generic use of XCAP.

Cheers,
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi,

I've implemented basic get/put/delete operation with XCAP server, added
support of resource-lists and xcap-caps functionality.
Now I'm trying to integrate it into Sip Communicator, could you please tell
me which things need to be synchronized?
I've take a look into another protocol implementation and noticed that only
serverStoredGroupListeners is synchronized.
All other operations with ContactGroup and Contact are not synchronized and
only events are fired - is it correct or I've missed something ?

Thanks, Grigorii

···

2010/5/1 Emil Ivov <emcho@sip-communicator.org>

Hey folks,

На 01.05.10 12:22, Werner Dittmann написа:
> 1) I'll check 4285 again to see what are the pros/cons of partial
> operation and if it is necessary to have this in a first step.
>
> 2) need to make up my mind first :slight_smile:

Yes, we should probably discuss these. At the end of the day, what we
really need here is:

1. Make our SIP protocol provider retrieve contacts from the server just
as most protocol would.
2. Make sure that what we implement works with popular deployments and
server implementations of XCAP but only for the contact list storage use
case (and I don't think there's an awful lot of them).

Supporting authorization policies is therefore also an important part,
although probably not the one with the highest priority. Could keep it
for after we have a first working implementation.

>> 3. How XCAP layer should look like?
>> It has to be abstract as much as possible (it will provides all
>> functionality through interfaces and events, will contain all
validation,
>> updating logic and so on)

Well that's kind of the purpose of our operation sets so I don't think
we'd need to introduce another abstraction layer here. This doesn't mean
you would have to dump all the code in ServerStoredContactListSipImpl,
of course.

You could still add an xcap package in impl.protocol.sip and implement
utility classes in there but they should be built for
ServerStoredContactListSipImpl rather than a generic use of XCAP.

Cheers,
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hey Grigorii,

На 07.05.10 11:30, Grigorii Balutsel написа:

Hi,

I've implemented basic get/put/delete operation with XCAP server, added
support of resource-lists and xcap-caps functionality.

Way to go! That's a great start!

Now I'm trying to integrate it into Sip Communicator, could you please
tell me which things need to be synchronized?
I've take a look into another protocol implementation and noticed that
only serverStoredGroupListeners is synchronized.
All other operations with ContactGroup and Contact are not synchronized
and only events are fired - is it correct or I've missed something ?

Well access to listeners does indeed need to be synced but that's fairly
trivial. The rest is really protocol dependent and therefore up to you.
Imagine for example, that you are looping over a list of objects in the
bundle start thread. If it is important for you to prevent others (e.g.
events originating in the jain-sip and xcap threads) to mess with your
list during that time, then you sync. If you think there's no way for
this to happen or if you believe it won't be a problem then you don't.

It could probably even make sense to postpone the reflection for a time
where you know what situations are possible to occur in your implementation.

Hope this helps,
Emil

···

Thanks, Grigorii

2010/5/1 Emil Ivov <emcho@sip-communicator.org
<mailto:emcho@sip-communicator.org>>

    Hey folks,

    На 01.05.10 12:22, Werner Dittmann написа:
    > 1) I'll check 4285 again to see what are the pros/cons of partial
    > operation and if it is necessary to have this in a first step.
    >
    > 2) need to make up my mind first :slight_smile:

    Yes, we should probably discuss these. At the end of the day, what we
    really need here is:

    1. Make our SIP protocol provider retrieve contacts from the server just
    as most protocol would.
    2. Make sure that what we implement works with popular deployments and
    server implementations of XCAP but only for the contact list storage use
    case (and I don't think there's an awful lot of them).

    Supporting authorization policies is therefore also an important part,
    although probably not the one with the highest priority. Could keep it
    for after we have a first working implementation.

    >> 3. How XCAP layer should look like?
    >> It has to be abstract as much as possible (it will provides all
    >> functionality through interfaces and events, will contain all
    validation,
    >> updating logic and so on)

    Well that's kind of the purpose of our operation sets so I don't think
    we'd need to introduce another abstraction layer here. This doesn't mean
    you would have to dump all the code in ServerStoredContactListSipImpl,
    of course.

    You could still add an xcap package in impl.protocol.sip and implement
    utility classes in there but they should be built for
    ServerStoredContactListSipImpl rather than a generic use of XCAP.

    Cheers,
    Emil

    ---------------------------------------------------------------------
    To unsubscribe, e-mail:
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    For additional commands, e-mail:
    dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hello,

During this week I've almost added support of XCap groups into Sip
Communicator.

I've found some things that need to be resolved:

   1. I didn't find appropriate way how to detect that XCAP server doesn't
   support partial update. According to RFC server capabilities should be
   written in xcap-caps but all tested servers that support partial updated
   don't write anything. The only solution I've found - try to use partial
   update operation, if it's failed with special HTTP code (Unsupported)
   remember it and use full update operation in the future.
   2. SIP and XCAP users can be different.

2.1 Different users:

sip_user@example.com - SIP user.

xcap_user@xcap.example.com - XCAP user.

2.2 The same users:

user@example.com - SIP user.

user@xcap.example.com - XCAP user.

What is the correct point?

   1. When REGISTRAR is failed user still has opportunity to create
   groups/contacts. Is it correct?
   2. Can someone tell me how contact group creation is designed? First only
   MetaContactGroup is created, then if user want to create contact inside it -
   this group created as protocol specific group. Am I right or did I miss
   something?
   3. I think next week I will have something to check in, can someone help
   me to configure SVN branch? Which SVN client is better to use?

Thanks, Grigorii

···

7 мая 2010 г. 13:58 пользователь Emil Ivov <emcho@sip-communicator.org>написал:

Hey Grigorii,

На 07.05.10 11:30, Grigorii Balutsel написа:
> Hi,
>
> I've implemented basic get/put/delete operation with XCAP server, added
> support of resource-lists and xcap-caps functionality.

Way to go! That's a great start!

> Now I'm trying to integrate it into Sip Communicator, could you please
> tell me which things need to be synchronized?
> I've take a look into another protocol implementation and noticed that
> only serverStoredGroupListeners is synchronized.
> All other operations with ContactGroup and Contact are not synchronized
> and only events are fired - is it correct or I've missed something ?

Well access to listeners does indeed need to be synced but that's fairly
trivial. The rest is really protocol dependent and therefore up to you.
Imagine for example, that you are looping over a list of objects in the
bundle start thread. If it is important for you to prevent others (e.g.
events originating in the jain-sip and xcap threads) to mess with your
list during that time, then you sync. If you think there's no way for
this to happen or if you believe it won't be a problem then you don't.

It could probably even make sense to postpone the reflection for a time
where you know what situations are possible to occur in your
implementation.

Hope this helps,
Emil
>
> Thanks, Grigorii
>
> 2010/5/1 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
>
> Hey folks,
>
> На 01.05.10 12:22, Werner Dittmann написа:
> > 1) I'll check 4285 again to see what are the pros/cons of partial
> > operation and if it is necessary to have this in a first step.
> >
> > 2) need to make up my mind first :slight_smile:
>
> Yes, we should probably discuss these. At the end of the day, what we
> really need here is:
>
> 1. Make our SIP protocol provider retrieve contacts from the server
just
> as most protocol would.
> 2. Make sure that what we implement works with popular deployments
and
> server implementations of XCAP but only for the contact list storage
use
> case (and I don't think there's an awful lot of them).
>
> Supporting authorization policies is therefore also an important
part,
> although probably not the one with the highest priority. Could keep
it
> for after we have a first working implementation.
>
> >> 3. How XCAP layer should look like?
> >> It has to be abstract as much as possible (it will provides all
> >> functionality through interfaces and events, will contain all
> validation,
> >> updating logic and so on)
>
> Well that's kind of the purpose of our operation sets so I don't
think
> we'd need to introduce another abstraction layer here. This doesn't
mean
> you would have to dump all the code in
ServerStoredContactListSipImpl,
> of course.
>
> You could still add an xcap package in impl.protocol.sip and
implement
> utility classes in there but they should be built for
> ServerStoredContactListSipImpl rather than a generic use of XCAP.
>
> Cheers,
> Emil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> For additional commands, e-mail:
> dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31


#7

Hey Grigorii,

На 14.05.10 16:07, Grigorii Balutsel написа:

Hello,

During this week I’ve almost added support of XCap groups into Sip
Communicator.

Very glad to hear this! Way to go! :slight_smile:

I’ve found some things that need to be resolved:

   1. I didn’t find appropriate way how to detect that XCAP server
      doesn’t support partial update. According to RFC server
      capabilities should be written in xcap-caps but all tested servers
      that support partial updated don’t write anything. The only
      solution I’ve found – try to use partial update operation, if it’s
      failed with special HTTP code (Unsupported) remember it and use
      full update operation in the future.
   2. SIP and XCAP users can be different.

2.1 Different users:

sip_user@example.com <mailto:sip_user@example.com> – SIP user.

xcap_user@xcap.example.com <mailto:xcap_user@xcap.example.com> – XCAP user.

2.2 The same users:

user@example.com <mailto:user@example.com> – SIP user.

user@xcap.example.com <mailto:user@xcap.example.com> – XCAP user.

SIP Communicator's behaviour in such cases is to assume the most common
option and allow users to override it when creating their accounts. This
means that you would need to add the options in the SIP account wizard,
in either the advanced tab, if there are only a few, or in a separate
tab, if you think more are necessary.

What is the correct point?

   3. When REGISTRAR is failed user still has opportunity to create
      groups/contacts. Is it correct?

I am not sure I understand the question. Are you saying that users are
able to create groups in SIP accounts that are not registered and
wondering whether this is correct, or, are you asking whether you should
allow users to create groups and add contacts to their XCAP account even
when their SIP account is not registered?

   4. Can someone tell me how contact group creation is designed? First
      only MetaContactGroup is created, then if user want to create
      contact inside it - this group created as protocol specific group.
      Am I right or did I miss something?

Exactly.

   5. I think next week I will have something to check in, can someone
      help me to configure SVN branch?

Yes, there is one now (gsoc10/sc-xcap) but you'll only have the
possibility to check it out. I would need to have your java.net user
name (as per my off-list mail) in order to give you write access to it.

Which SVN client is better to use?

That's really a personal preference. Some of the developers prefer using
the client integrated in the IDE, others go for the command line, others
yet use git, etc. It's up to you really. Pick the option that you are
most comfortable with at this point. You can always change later if you
are in the mood for experimenting.

Cheers,
Emil

···

Thanks, Grigorii

7 мая 2010 г. 13:58 пользователь Emil Ivov <emcho@sip-communicator.org > <mailto:emcho@sip-communicator.org>> написал:

    Hey Grigorii,

    На 07.05.10 11:30, Grigorii Balutsel написа:
    > Hi,
    >
    > I've implemented basic get/put/delete operation with XCAP server,
    added
    > support of resource-lists and xcap-caps functionality.

    Way to go! That's a great start!

    > Now I'm trying to integrate it into Sip Communicator, could you please
    > tell me which things need to be synchronized?
    > I've take a look into another protocol implementation and noticed that
    > only serverStoredGroupListeners is synchronized.
    > All other operations with ContactGroup and Contact are not
    synchronized
    > and only events are fired - is it correct or I've missed something ?

    Well access to listeners does indeed need to be synced but that's fairly
    trivial. The rest is really protocol dependent and therefore up to you.
    Imagine for example, that you are looping over a list of objects in the
    bundle start thread. If it is important for you to prevent others (e.g.
    events originating in the jain-sip and xcap threads) to mess with your
    list during that time, then you sync. If you think there's no way for
    this to happen or if you believe it won't be a problem then you don't.

    It could probably even make sense to postpone the reflection for a time
    where you know what situations are possible to occur in your
    implementation.

    Hope this helps,
    Emil
    >
    > Thanks, Grigorii
    >
    > 2010/5/1 Emil Ivov <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    >
    > Hey folks,
    >
    > На 01.05.10 12:22, Werner Dittmann написа:
    > > 1) I'll check 4285 again to see what are the pros/cons of
    partial
    > > operation and if it is necessary to have this in a first
    step.
    > >
    > > 2) need to make up my mind first :slight_smile:
    >
    > Yes, we should probably discuss these. At the end of the day,
    what we
    > really need here is:
    >
    > 1. Make our SIP protocol provider retrieve contacts from the
    server just
    > as most protocol would.
    > 2. Make sure that what we implement works with popular
    deployments and
    > server implementations of XCAP but only for the contact list
    storage use
    > case (and I don't think there's an awful lot of them).
    >
    > Supporting authorization policies is therefore also an
    important part,
    > although probably not the one with the highest priority. Could
    keep it
    > for after we have a first working implementation.
    >
    > >> 3. How XCAP layer should look like?
    > >> It has to be abstract as much as possible (it will provides all
    > >> functionality through interfaces and events, will contain all
    > validation,
    > >> updating logic and so on)
    >
    > Well that's kind of the purpose of our operation sets so I
    don't think
    > we'd need to introduce another abstraction layer here. This
    doesn't mean
    > you would have to dump all the code in
    ServerStoredContactListSipImpl,
    > of course.
    >
    > You could still add an xcap package in impl.protocol.sip and
    implement
    > utility classes in there but they should be built for
    > ServerStoredContactListSipImpl rather than a generic use of XCAP.
    >
    > Cheers,
    > Emil
    >
    >
    >
    ---------------------------------------------------------------------
    > To unsubscribe, e-mail:
    > dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > For additional commands, e-mail:
    > dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    >
    >

    --
    Emil Ivov, Ph.D. 67000 Strasbourg,
    Project Lead France
    SIP Communicator
    emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
                  PHONE: +33.1.77.62.43.30
    http://sip-communicator.org FAX: +33.1.77.62.47.31

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

dear:

I had a problem when i run the SIP Communicator .the bellow is the error
log:

20:44:55.006 =D1=CF=D6=D8:
impl.neomedia.device.DeviceConfiguration.registerCustomRenderers().1005
Failed to register custom Renderer

net.java.sip.communicator.impl.neomedia.jmfext.media.renderer.video.JAWTRen=

derer
with JMF.

## Building flow graph for: null
## Building Track: 0
## Input: RGB, 640x480, FrameRate=3D30.0, 24-bit, Masks=3D3:2:1,
PixelStrid=
e=3D3,
LineStride=3D1920
## Custom options specified.
## A custom codec is specified:

net.java.sip.communicator.impl.neomedia.codec.video.h264.JNIEncoder@19ab9c5

XX The input format is not compatible with the given codec plugin:

net.java.sip.communicator.impl.neomedia.codec.video.h264.JNIEncoder@19ab9c5

XX Failed to realize: com.sun.media.ProcessEngine@437dcb
XX Cannot build a flow graph with the customized options:
XX Unable to transcode format: RGB, 640x480, FrameRate=3D30.0, 24-bit,
Masks=3D3:2:1, PixelStride=3D3, LineStride=3D1920
XX to: H264/RTP
XX outputting to: RAW/RTP
XX Unable to add customed codecs:
XX

net.java.sip.communicator.impl.neomedia.codec.video.h264.JNIEncoder@19ab9c5

···

XX Error: Unable to realize com.sun.media.ProcessEngine@437dcb
$$ Profile: instantiation: 0 ms

How to solve this problem? I hope you can help me. thanks!

Kind regards,
Kaiduan Cao


#9

Hello,

I have some question:

How to say to the user that during login SIP connection is OK, but XCAP
connection is failed?

I've found that ProtocolProviderService has method register if I put XCAP
connect there and if it is failed it will mean that SIP connection is failed
too.

Thanks, Grigorii

···

2010/5/15 Emil Ivov <emcho@sip-communicator.org>

Hey Grigorii,

На 14.05.10 16:07, Grigorii Balutsel написа:
> Hello,
>
> During this week I've almost added support of XCap groups into Sip
> Communicator.

Very glad to hear this! Way to go! :slight_smile:

> I've found some things that need to be resolved:
>
> 1. I didn't find appropriate way how to detect that XCAP server
> doesn't support partial update. According to RFC server
> capabilities should be written in xcap-caps but all tested servers
> that support partial updated don't write anything. The only
> solution I've found - try to use partial update operation, if it's
> failed with special HTTP code (Unsupported) remember it and use
> full update operation in the future.
> 2. SIP and XCAP users can be different.
>
> 2.1 Different users:
>
> sip_user@example.com <mailto:sip_user@example.com> - SIP user.
>
> xcap_user@xcap.example.com <mailto:xcap_user@xcap.example.com> - XCAP
user.
>
> 2.2 The same users:
>
> user@example.com <mailto:user@example.com> - SIP user.
>
> user@xcap.example.com <mailto:user@xcap.example.com> - XCAP user.

SIP Communicator's behaviour in such cases is to assume the most common
option and allow users to override it when creating their accounts. This
means that you would need to add the options in the SIP account wizard,
in either the advanced tab, if there are only a few, or in a separate
tab, if you think more are necessary.

> What is the correct point?
>
> 3. When REGISTRAR is failed user still has opportunity to create
> groups/contacts. Is it correct?

I am not sure I understand the question. Are you saying that users are
able to create groups in SIP accounts that are not registered and
wondering whether this is correct, or, are you asking whether you should
allow users to create groups and add contacts to their XCAP account even
when their SIP account is not registered?

> 4. Can someone tell me how contact group creation is designed? First
> only MetaContactGroup is created, then if user want to create
> contact inside it - this group created as protocol specific group.
> Am I right or did I miss something?

Exactly.

> 5. I think next week I will have something to check in, can someone
> help me to configure SVN branch?

Yes, there is one now (gsoc10/sc-xcap) but you'll only have the
possibility to check it out. I would need to have your java.net user
name (as per my off-list mail) in order to give you write access to it.

> Which SVN client is better to use?

That's really a personal preference. Some of the developers prefer using
the client integrated in the IDE, others go for the command line, others
yet use git, etc. It's up to you really. Pick the option that you are
most comfortable with at this point. You can always change later if you
are in the mood for experimenting.

Cheers,
Emil
>
> Thanks, Grigorii
>
>
> 7 мая 2010 г. 13:58 пользователь Emil Ivov <emcho@sip-communicator.org > > <mailto:emcho@sip-communicator.org>> написал:
>
> Hey Grigorii,
>
> На 07.05.10 11:30, Grigorii Balutsel написа:
> > Hi,
> >
> > I've implemented basic get/put/delete operation with XCAP server,
> added
> > support of resource-lists and xcap-caps functionality.
>
> Way to go! That's a great start!
>
> > Now I'm trying to integrate it into Sip Communicator, could you
please
> > tell me which things need to be synchronized?
> > I've take a look into another protocol implementation and noticed
that
> > only serverStoredGroupListeners is synchronized.
> > All other operations with ContactGroup and Contact are not
> synchronized
> > and only events are fired - is it correct or I've missed something
?
>
> Well access to listeners does indeed need to be synced but that's
fairly
> trivial. The rest is really protocol dependent and therefore up to
you.
> Imagine for example, that you are looping over a list of objects in
the
> bundle start thread. If it is important for you to prevent others
(e.g.
> events originating in the jain-sip and xcap threads) to mess with
your
> list during that time, then you sync. If you think there's no way for
> this to happen or if you believe it won't be a problem then you
don't.
>
> It could probably even make sense to postpone the reflection for a
time
> where you know what situations are possible to occur in your
> implementation.
>
> Hope this helps,
> Emil
> >
> > Thanks, Grigorii
> >
> > 2010/5/1 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>
> >
> > Hey folks,
> >
> > На 01.05.10 12:22, Werner Dittmann написа:
> > > 1) I'll check 4285 again to see what are the pros/cons of
> partial
> > > operation and if it is necessary to have this in a first
> step.
> > >
> > > 2) need to make up my mind first :slight_smile:
> >
> > Yes, we should probably discuss these. At the end of the day,
> what we
> > really need here is:
> >
> > 1. Make our SIP protocol provider retrieve contacts from the
> server just
> > as most protocol would.
> > 2. Make sure that what we implement works with popular
> deployments and
> > server implementations of XCAP but only for the contact list
> storage use
> > case (and I don't think there's an awful lot of them).
> >
> > Supporting authorization policies is therefore also an
> important part,
> > although probably not the one with the highest priority. Could
> keep it
> > for after we have a first working implementation.
> >
> > >> 3. How XCAP layer should look like?
> > >> It has to be abstract as much as possible (it will provides
all
> > >> functionality through interfaces and events, will contain
all
> > validation,
> > >> updating logic and so on)
> >
> > Well that's kind of the purpose of our operation sets so I
> don't think
> > we'd need to introduce another abstraction layer here. This
> doesn't mean
> > you would have to dump all the code in
> ServerStoredContactListSipImpl,
> > of course.
> >
> > You could still add an xcap package in impl.protocol.sip and
> implement
> > utility classes in there but they should be built for
> > ServerStoredContactListSipImpl rather than a generic use of
XCAP.
> >
> > Cheers,
> > Emil
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
> > For additional commands, e-mail:
> > dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>
> >
> >
>
> --
> Emil Ivov, Ph.D. 67000 Strasbourg,
> Project Lead France
> SIP Communicator
> emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> PHONE: +33.1.77.62.43.30
> http://sip-communicator.org FAX:
+33.1.77.62.47.31
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31


#10

Hello,

One additional question:
How to add specific libraries into the project?
I've added specific lines into felix.client.run.properties:

felix.auto.start.85= \
reference:file:lib/bundle/httpclient-4.0.1.jar \
reference:file:lib/bundle/httpcore-4.0.1.jar \
reference:file:lib/bundle/httpmime-4.0.1.jar

but when I run it I still have java.lang.NoClassDefFoundError:
org/apache/http/auth/Credentials
If I put them into protocol-sip.jar everything works fine.

Did I miss something?

Thanks, Grigorii

···

18 мая 2010 г. 17:25 пользователь Grigorii Balutsel < grigorii.balutsel@gmail.com> написал:

Hello,

I have some question:

How to say to the user that during login SIP connection is OK, but XCAP
connection is failed?

I've found that ProtocolProviderService has method register if I put XCAP
connect there and if it is failed it will mean that SIP connection is failed
too.

Thanks, Grigorii

2010/5/15 Emil Ivov <emcho@sip-communicator.org>

Hey Grigorii,

На 14.05.10 16:07, Grigorii Balutsel написа:
> Hello,
>
> During this week I've almost added support of XCap groups into Sip
> Communicator.

Very glad to hear this! Way to go! :slight_smile:

> I've found some things that need to be resolved:
>
> 1. I didn't find appropriate way how to detect that XCAP server
> doesn't support partial update. According to RFC server
> capabilities should be written in xcap-caps but all tested servers
> that support partial updated don't write anything. The only
> solution I've found - try to use partial update operation, if it's
> failed with special HTTP code (Unsupported) remember it and use
> full update operation in the future.
> 2. SIP and XCAP users can be different.
>
> 2.1 Different users:
>
> sip_user@example.com <mailto:sip_user@example.com> - SIP user.
>
> xcap_user@xcap.example.com <mailto:xcap_user@xcap.example.com> - XCAP
user.
>
> 2.2 The same users:
>
> user@example.com <mailto:user@example.com> - SIP user.
>
> user@xcap.example.com <mailto:user@xcap.example.com> - XCAP user.

SIP Communicator's behaviour in such cases is to assume the most common
option and allow users to override it when creating their accounts. This
means that you would need to add the options in the SIP account wizard,
in either the advanced tab, if there are only a few, or in a separate
tab, if you think more are necessary.

> What is the correct point?
>
> 3. When REGISTRAR is failed user still has opportunity to create
> groups/contacts. Is it correct?

I am not sure I understand the question. Are you saying that users are
able to create groups in SIP accounts that are not registered and
wondering whether this is correct, or, are you asking whether you should
allow users to create groups and add contacts to their XCAP account even
when their SIP account is not registered?

> 4. Can someone tell me how contact group creation is designed? First
> only MetaContactGroup is created, then if user want to create
> contact inside it - this group created as protocol specific group.
> Am I right or did I miss something?

Exactly.

> 5. I think next week I will have something to check in, can someone
> help me to configure SVN branch?

Yes, there is one now (gsoc10/sc-xcap) but you'll only have the
possibility to check it out. I would need to have your java.net user
name (as per my off-list mail) in order to give you write access to it.

> Which SVN client is better to use?

That's really a personal preference. Some of the developers prefer using
the client integrated in the IDE, others go for the command line, others
yet use git, etc. It's up to you really. Pick the option that you are
most comfortable with at this point. You can always change later if you
are in the mood for experimenting.

Cheers,
Emil
>
> Thanks, Grigorii
>
>
> 7 мая 2010 г. 13:58 пользователь Emil Ivov <emcho@sip-communicator.org >> > <mailto:emcho@sip-communicator.org>> написал:
>
> Hey Grigorii,
>
> На 07.05.10 11:30, Grigorii Balutsel написа:
> > Hi,
> >
> > I've implemented basic get/put/delete operation with XCAP server,
> added
> > support of resource-lists and xcap-caps functionality.
>
> Way to go! That's a great start!
>
> > Now I'm trying to integrate it into Sip Communicator, could you
please
> > tell me which things need to be synchronized?
> > I've take a look into another protocol implementation and noticed
that
> > only serverStoredGroupListeners is synchronized.
> > All other operations with ContactGroup and Contact are not
> synchronized
> > and only events are fired - is it correct or I've missed
something ?
>
> Well access to listeners does indeed need to be synced but that's
fairly
> trivial. The rest is really protocol dependent and therefore up to
you.
> Imagine for example, that you are looping over a list of objects in
the
> bundle start thread. If it is important for you to prevent others
(e.g.
> events originating in the jain-sip and xcap threads) to mess with
your
> list during that time, then you sync. If you think there's no way
for
> this to happen or if you believe it won't be a problem then you
don't.
>
> It could probably even make sense to postpone the reflection for a
time
> where you know what situations are possible to occur in your
> implementation.
>
> Hope this helps,
> Emil
> >
> > Thanks, Grigorii
> >
> > 2010/5/1 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>
> >
> > Hey folks,
> >
> > На 01.05.10 12:22, Werner Dittmann написа:
> > > 1) I'll check 4285 again to see what are the pros/cons of
> partial
> > > operation and if it is necessary to have this in a first
> step.
> > >
> > > 2) need to make up my mind first :slight_smile:
> >
> > Yes, we should probably discuss these. At the end of the day,
> what we
> > really need here is:
> >
> > 1. Make our SIP protocol provider retrieve contacts from the
> server just
> > as most protocol would.
> > 2. Make sure that what we implement works with popular
> deployments and
> > server implementations of XCAP but only for the contact list
> storage use
> > case (and I don't think there's an awful lot of them).
> >
> > Supporting authorization policies is therefore also an
> important part,
> > although probably not the one with the highest priority. Could
> keep it
> > for after we have a first working implementation.
> >
> > >> 3. How XCAP layer should look like?
> > >> It has to be abstract as much as possible (it will provides
all
> > >> functionality through interfaces and events, will contain
all
> > validation,
> > >> updating logic and so on)
> >
> > Well that's kind of the purpose of our operation sets so I
> don't think
> > we'd need to introduce another abstraction layer here. This
> doesn't mean
> > you would have to dump all the code in
> ServerStoredContactListSipImpl,
> > of course.
> >
> > You could still add an xcap package in impl.protocol.sip and
> implement
> > utility classes in there but they should be built for
> > ServerStoredContactListSipImpl rather than a generic use of
XCAP.
> >
> > Cheers,
> > Emil
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
> > For additional commands, e-mail:
> > dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>
> >
> >
>
> --
> Emil Ivov, Ph.D. 67000 Strasbourg,
> Project Lead France
> SIP Communicator
> emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> PHONE: +33.1.77.62.43.30
> http://sip-communicator.org FAX:
+33.1.77.62.47.31
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31


#11

Hey Grigorii,

На 18.05.10 16:25, Grigorii Balutsel написа:

Hello,

I have some question:

How to say to the user that during login SIP connection is OK, but XCAP
connection is failed?

I’ve found that ProtocolProviderService has method register if I put
XCAP connect there and if it is failed it will mean that SIP connection
is failed too.

That's a good question (and I guess, one of the many joys when trying to
do presence with SIP :slight_smile: ).

The reason this is tricky is that we don't really know whether XCAP was
supposed to be working or not. Since we can't expect users to always
manually configure their XCAP servers we'll be trying to auto detect it
(and that would probably mean a blind stab).

Therefore it would probably be best to handle failures by silently
logging them and without bothering the user. We may try to refine this
later on.

How does this sound?

Cheers,
Emil

···

Thanks, Grigorii

2010/5/15 Emil Ivov <emcho@sip-communicator.org
<mailto:emcho@sip-communicator.org>>

    Hey Grigorii,

    На 14.05.10 16:07, Grigorii Balutsel написа:
    > Hello,
    >
    > During this week I’ve almost added support of XCap groups into Sip
    > Communicator.

    Very glad to hear this! Way to go! :slight_smile:

    > I’ve found some things that need to be resolved:
    >
    > 1. I didn’t find appropriate way how to detect that XCAP server
    > doesn’t support partial update. According to RFC server
    > capabilities should be written in xcap-caps but all tested
    servers
    > that support partial updated don’t write anything. The only
    > solution I’ve found – try to use partial update operation,
    if it’s
    > failed with special HTTP code (Unsupported) remember it and use
    > full update operation in the future.
    > 2. SIP and XCAP users can be different.
    >
    > 2.1 Different users:
    >
    > sip_user@example.com <mailto:sip_user@example.com>
    <mailto:sip_user@example.com <mailto:sip_user@example.com>> – SIP user.
    >
    > xcap_user@xcap.example.com <mailto:xcap_user@xcap.example.com>
    <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>> – XCAP user.
    >
    > 2.2 The same users:
    >
    > user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>> – SIP user.
    >
    > user@xcap.example.com <mailto:user@xcap.example.com>
    <mailto:user@xcap.example.com <mailto:user@xcap.example.com>> – XCAP
    user.

    SIP Communicator's behaviour in such cases is to assume the most common
    option and allow users to override it when creating their accounts. This
    means that you would need to add the options in the SIP account wizard,
    in either the advanced tab, if there are only a few, or in a separate
    tab, if you think more are necessary.

    > What is the correct point?
    >
    > 3. When REGISTRAR is failed user still has opportunity to create
    > groups/contacts. Is it correct?

    I am not sure I understand the question. Are you saying that users are
    able to create groups in SIP accounts that are not registered and
    wondering whether this is correct, or, are you asking whether you should
    allow users to create groups and add contacts to their XCAP account even
    when their SIP account is not registered?

    > 4. Can someone tell me how contact group creation is designed?
    First
    > only MetaContactGroup is created, then if user want to create
    > contact inside it - this group created as protocol specific
    group.
    > Am I right or did I miss something?

    Exactly.

    > 5. I think next week I will have something to check in, can someone
    > help me to configure SVN branch?

    Yes, there is one now (gsoc10/sc-xcap) but you'll only have the
    possibility to check it out. I would need to have your java.net
    <http://java.net> user
    name (as per my off-list mail) in order to give you write access to it.

    > Which SVN client is better to use?

    That's really a personal preference. Some of the developers prefer using
    the client integrated in the IDE, others go for the command line, others
    yet use git, etc. It's up to you really. Pick the option that you are
    most comfortable with at this point. You can always change later if you
    are in the mood for experimenting.

    Cheers,
    Emil
    >
    > Thanks, Grigorii
    >
    >
    > 7 мая 2010 г. 13:58 пользователь Emil Ivov
    <emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>> написал:
    >
    > Hey Grigorii,
    >
    > На 07.05.10 11:30, Grigorii Balutsel написа:
    > > Hi,
    > >
    > > I've implemented basic get/put/delete operation with XCAP
    server,
    > added
    > > support of resource-lists and xcap-caps functionality.
    >
    > Way to go! That's a great start!
    >
    > > Now I'm trying to integrate it into Sip Communicator, could
    you please
    > > tell me which things need to be synchronized?
    > > I've take a look into another protocol implementation and
    noticed that
    > > only serverStoredGroupListeners is synchronized.
    > > All other operations with ContactGroup and Contact are not
    > synchronized
    > > and only events are fired - is it correct or I've missed
    something ?
    >
    > Well access to listeners does indeed need to be synced but
    that's fairly
    > trivial. The rest is really protocol dependent and therefore
    up to you.
    > Imagine for example, that you are looping over a list of
    objects in the
    > bundle start thread. If it is important for you to prevent
    others (e.g.
    > events originating in the jain-sip and xcap threads) to mess
    with your
    > list during that time, then you sync. If you think there's no
    way for
    > this to happen or if you believe it won't be a problem then
    you don't.
    >
    > It could probably even make sense to postpone the reflection
    for a time
    > where you know what situations are possible to occur in your
    > implementation.
    >
    > Hope this helps,
    > Emil
    > >
    > > Thanks, Grigorii
    > >
    > > 2010/5/1 Emil Ivov <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>
    > >
    > > Hey folks,
    > >
    > > На 01.05.10 12:22, Werner Dittmann написа:
    > > > 1) I'll check 4285 again to see what are the pros/cons of
    > partial
    > > > operation and if it is necessary to have this in a
    first
    > step.
    > > >
    > > > 2) need to make up my mind first :slight_smile:
    > >
    > > Yes, we should probably discuss these. At the end of the
    day,
    > what we
    > > really need here is:
    > >
    > > 1. Make our SIP protocol provider retrieve contacts from the
    > server just
    > > as most protocol would.
    > > 2. Make sure that what we implement works with popular
    > deployments and
    > > server implementations of XCAP but only for the contact list
    > storage use
    > > case (and I don't think there's an awful lot of them).
    > >
    > > Supporting authorization policies is therefore also an
    > important part,
    > > although probably not the one with the highest priority.
    Could
    > keep it
    > > for after we have a first working implementation.
    > >
    > > >> 3. How XCAP layer should look like?
    > > >> It has to be abstract as much as possible (it will
    provides all
    > > >> functionality through interfaces and events, will
    contain all
    > > validation,
    > > >> updating logic and so on)
    > >
    > > Well that's kind of the purpose of our operation sets so I
    > don't think
    > > we'd need to introduce another abstraction layer here. This
    > doesn't mean
    > > you would have to dump all the code in
    > ServerStoredContactListSipImpl,
    > > of course.
    > >
    > > You could still add an xcap package in impl.protocol.sip and
    > implement
    > > utility classes in there but they should be built for
    > > ServerStoredContactListSipImpl rather than a generic use
    of XCAP.
    > >
    > > Cheers,
    > > Emil
    > >
    > >
    > >
    >
    ---------------------------------------------------------------------
    > > To unsubscribe, e-mail:
    > > dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
    > > For additional commands, e-mail:
    > > dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>
    > >
    > >
    >
    > --
    > Emil Ivov, Ph.D. 67000 Strasbourg,
    > Project Lead France
    > SIP Communicator
    > emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > PHONE: +33.1.77.62.43.30
    > http://sip-communicator.org FAX:
    +33.1.77.62.47.31
    >
    >

    --
    Emil Ivov, Ph.D. 67000 Strasbourg,
    Project Lead France
    SIP Communicator
    emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
                  PHONE: +33.1.77.62.43.30
    http://sip-communicator.org FAX: +33.1.77.62.47.31

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Hello Emil,

It sounds good, so for now I'll add the following:
When register is called and SIP successfully connected I will try to connect
to XCAP server, if it is failed - I will only log it. When user will try to
add some contact/group I will throw OperationFailedException.NOT_FOUND.

Can you please tell me how to add specific libraries into the project?
I've added specific lines into felix.client.run.properties:

felix.auto.start.85= \
reference:file:lib/bundle/httpclient-4.0.1.jar \
reference:file:lib/bundle/httpcore-4.0.1.jar \
reference:file:lib/bundle/httpmime-4.0.1.jar

but when I run it I still have java.lang.NoClassDefFoundError:
org/apache/http/auth/Credentials
If I put them (files inside libraries) into protocol-sip.jar everything
works fine.

Thanks, Grigorii

···

2010/5/19 Emil Ivov <emcho@sip-communicator.org>

Hey Grigorii,

На 18.05.10 16:25, Grigorii Balutsel написа:
> Hello,
>
> I have some question:
>
> How to say to the user that during login SIP connection is OK, but XCAP
> connection is failed?
>
> I've found that ProtocolProviderService has method register if I put
> XCAP connect there and if it is failed it will mean that SIP connection
> is failed too.

That's a good question (and I guess, one of the many joys when trying to
do presence with SIP :slight_smile: ).

The reason this is tricky is that we don't really know whether XCAP was
supposed to be working or not. Since we can't expect users to always
manually configure their XCAP servers we'll be trying to auto detect it
(and that would probably mean a blind stab).

Therefore it would probably be best to handle failures by silently
logging them and without bothering the user. We may try to refine this
later on.

How does this sound?

Cheers,
Emil
>
> Thanks, Grigorii
>
>
> 2010/5/15 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
>
> Hey Grigorii,
>
> На 14.05.10 16:07, Grigorii Balutsel написа:
> > Hello,
> >
> > During this week I've almost added support of XCap groups into Sip
> > Communicator.
>
> Very glad to hear this! Way to go! :slight_smile:
>
> > I've found some things that need to be resolved:
> >
> > 1. I didn't find appropriate way how to detect that XCAP server
> > doesn't support partial update. According to RFC server
> > capabilities should be written in xcap-caps but all tested
> servers
> > that support partial updated don't write anything. The only
> > solution I've found - try to use partial update operation,
> if it's
> > failed with special HTTP code (Unsupported) remember it and
use
> > full update operation in the future.
> > 2. SIP and XCAP users can be different.
> >
> > 2.1 Different users:
> >
> > sip_user@example.com <mailto:sip_user@example.com>
> <mailto:sip_user@example.com <mailto:sip_user@example.com>> - SIP
user.
> >
> > xcap_user@xcap.example.com <mailto:xcap_user@xcap.example.com>
> <mailto:xcap_user@xcap.example.com
> <mailto:xcap_user@xcap.example.com>> - XCAP user.
> >
> > 2.2 The same users:
> >
> > user@example.com <mailto:user@example.com>
> <mailto:user@example.com <mailto:user@example.com>> - SIP user.
> >
> > user@xcap.example.com <mailto:user@xcap.example.com>
> <mailto:user@xcap.example.com <mailto:user@xcap.example.com>> - XCAP
> user.
>
> SIP Communicator's behaviour in such cases is to assume the most
common
> option and allow users to override it when creating their accounts.
This
> means that you would need to add the options in the SIP account
wizard,
> in either the advanced tab, if there are only a few, or in a separate
> tab, if you think more are necessary.
>
> > What is the correct point?
> >
> > 3. When REGISTRAR is failed user still has opportunity to create
> > groups/contacts. Is it correct?
>
> I am not sure I understand the question. Are you saying that users
are
> able to create groups in SIP accounts that are not registered and
> wondering whether this is correct, or, are you asking whether you
should
> allow users to create groups and add contacts to their XCAP account
even
> when their SIP account is not registered?
>
> > 4. Can someone tell me how contact group creation is designed?
> First
> > only MetaContactGroup is created, then if user want to create
> > contact inside it - this group created as protocol specific
> group.
> > Am I right or did I miss something?
>
> Exactly.
>
> > 5. I think next week I will have something to check in, can
someone
> > help me to configure SVN branch?
>
> Yes, there is one now (gsoc10/sc-xcap) but you'll only have the
> possibility to check it out. I would need to have your java.net
> <http://java.net> user
> name (as per my off-list mail) in order to give you write access to
it.
>
> > Which SVN client is better to use?
>
> That's really a personal preference. Some of the developers prefer
using
> the client integrated in the IDE, others go for the command line,
others
> yet use git, etc. It's up to you really. Pick the option that you are
> most comfortable with at this point. You can always change later if
you
> are in the mood for experimenting.
>
> Cheers,
> Emil
> >
> > Thanks, Grigorii
> >
> >
> > 7 мая 2010 г. 13:58 пользователь Emil Ivov
> <emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>> написал:
> >
> > Hey Grigorii,
> >
> > На 07.05.10 11:30, Grigorii Balutsel написа:
> > > Hi,
> > >
> > > I've implemented basic get/put/delete operation with XCAP
> server,
> > added
> > > support of resource-lists and xcap-caps functionality.
> >
> > Way to go! That's a great start!
> >
> > > Now I'm trying to integrate it into Sip Communicator, could
> you please
> > > tell me which things need to be synchronized?
> > > I've take a look into another protocol implementation and
> noticed that
> > > only serverStoredGroupListeners is synchronized.
> > > All other operations with ContactGroup and Contact are not
> > synchronized
> > > and only events are fired - is it correct or I've missed
> something ?
> >
> > Well access to listeners does indeed need to be synced but
> that's fairly
> > trivial. The rest is really protocol dependent and therefore
> up to you.
> > Imagine for example, that you are looping over a list of
> objects in the
> > bundle start thread. If it is important for you to prevent
> others (e.g.
> > events originating in the jain-sip and xcap threads) to mess
> with your
> > list during that time, then you sync. If you think there's no
> way for
> > this to happen or if you believe it won't be a problem then
> you don't.
> >
> > It could probably even make sense to postpone the reflection
> for a time
> > where you know what situations are possible to occur in your
> > implementation.
> >
> > Hope this helps,
> > Emil
> > >
> > > Thanks, Grigorii
> > >
> > > 2010/5/1 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>>
> > >
> > > Hey folks,
> > >
> > > На 01.05.10 12:22, Werner Dittmann написа:
> > > > 1) I'll check 4285 again to see what are the pros/cons
of
> > partial
> > > > operation and if it is necessary to have this in a
> first
> > step.
> > > >
> > > > 2) need to make up my mind first :slight_smile:
> > >
> > > Yes, we should probably discuss these. At the end of the
> day,
> > what we
> > > really need here is:
> > >
> > > 1. Make our SIP protocol provider retrieve contacts from
the
> > server just
> > > as most protocol would.
> > > 2. Make sure that what we implement works with popular
> > deployments and
> > > server implementations of XCAP but only for the contact
list
> > storage use
> > > case (and I don't think there's an awful lot of them).
> > >
> > > Supporting authorization policies is therefore also an
> > important part,
> > > although probably not the one with the highest priority.
> Could
> > keep it
> > > for after we have a first working implementation.
> > >
> > > >> 3. How XCAP layer should look like?
> > > >> It has to be abstract as much as possible (it will
> provides all
> > > >> functionality through interfaces and events, will
> contain all
> > > validation,
> > > >> updating logic and so on)
> > >
> > > Well that's kind of the purpose of our operation sets so
I
> > don't think
> > > we'd need to introduce another abstraction layer here.
This
> > doesn't mean
> > > you would have to dump all the code in
> > ServerStoredContactListSipImpl,
> > > of course.
> > >
> > > You could still add an xcap package in impl.protocol.sip
and
> > implement
> > > utility classes in there but they should be built for
> > > ServerStoredContactListSipImpl rather than a generic use
> of XCAP.
> > >
> > > Cheers,
> > > Emil
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
> > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
> > > For additional commands, e-mail:
> > > dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>
> > > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>>
> > >
> > >
> >
> > --
> > Emil Ivov, Ph.D. 67000
Strasbourg,
> > Project Lead France
> > SIP Communicator
> > emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org <mailto:
emcho@sip-communicator.org>>
> > PHONE: +33.1.77.62.43.30
> > http://sip-communicator.org FAX:
> +33.1.77.62.47.31
> >
> >
>
> --
> Emil Ivov, Ph.D. 67000 Strasbourg,
> Project Lead France
> SIP Communicator
> emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> PHONE: +33.1.77.62.43.30
> http://sip-communicator.org FAX:
+33.1.77.62.47.31
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31


#13

На 19.05.10 13:45, Grigorii Balutsel написа:

Hello Emil,

It sounds good, so for now I'll add the following:
When register is called and SIP successfully connected I will try to
connect to XCAP server, if it is failed - I will only log it. When user
will try to add some contact/group I will throw
OperationFailedException.NOT_FOUND.

Doesn't sound like a good idea as it would make presence unusable for
providers that don't have XCAP (i.e. almost all). If XCAP fails in the
beginning, then everything should work as it currently does. The
MetaContactListService would take care of storing the contacts locally.

Can you please tell me how to add specific libraries into the project?
I've added specific lines into felix.client.run.properties:

felix.auto.start.85= \
reference:file:lib/bundle/httpclient-4.0.1.jar \
reference:file:lib/bundle/httpcore-4.0.1.jar \
reference:file:lib/bundle/httpmime-4.0.1.jar

There's already an httpcore bundle in SC. Is there any reason you are
not using that one?

Something else. With httpcore, we store the original jar in
lib/installer-excldue and then convert it into a bundle with the
bundle-httpcore target in the build.xml. You can use that as an example
for the other two libs.

but when I run it I still have java.lang.NoClassDefFoundError:
org/apache/http/auth/Credentials
If I put them (files inside libraries) into protocol-sip.jar everything
works fine.

Notice the Export-Package attribute that bundle-httpcore adds to the
httpcore.jar. You'd need this in order to tell felix what packages in
your bundle are to be made available for others.

Hope this helps,

Emil

···

Thanks, Grigorii

2010/5/19 Emil Ivov <emcho@sip-communicator.org
<mailto:emcho@sip-communicator.org>>

    Hey Grigorii,

    На 18.05.10 16:25, Grigorii Balutsel написа:
    > Hello,
    >
    > I have some question:
    >
    > How to say to the user that during login SIP connection is OK, but
    XCAP
    > connection is failed?
    >
    > I’ve found that ProtocolProviderService has method register if I put
    > XCAP connect there and if it is failed it will mean that SIP
    connection
    > is failed too.

    That's a good question (and I guess, one of the many joys when trying to
    do presence with SIP :slight_smile: ).

    The reason this is tricky is that we don't really know whether XCAP was
    supposed to be working or not. Since we can't expect users to always
    manually configure their XCAP servers we'll be trying to auto detect it
    (and that would probably mean a blind stab).

    Therefore it would probably be best to handle failures by silently
    logging them and without bothering the user. We may try to refine this
    later on.

    How does this sound?

    Cheers,
    Emil
    >
    > Thanks, Grigorii
    >
    >
    > 2010/5/15 Emil Ivov <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    >
    > Hey Grigorii,
    >
    > На 14.05.10 16:07, Grigorii Balutsel написа:
    > > Hello,
    > >
    > > During this week I’ve almost added support of XCap groups
    into Sip
    > > Communicator.
    >
    > Very glad to hear this! Way to go! :slight_smile:
    >
    > > I’ve found some things that need to be resolved:
    > >
    > > 1. I didn’t find appropriate way how to detect that XCAP
    server
    > > doesn’t support partial update. According to RFC server
    > > capabilities should be written in xcap-caps but all tested
    > servers
    > > that support partial updated don’t write anything. The
    only
    > > solution I’ve found – try to use partial update operation,
    > if it’s
    > > failed with special HTTP code (Unsupported) remember
    it and use
    > > full update operation in the future.
    > > 2. SIP and XCAP users can be different.
    > >
    > > 2.1 Different users:
    > >
    > > sip_user@example.com <mailto:sip_user@example.com>
    <mailto:sip_user@example.com <mailto:sip_user@example.com>>
    > <mailto:sip_user@example.com <mailto:sip_user@example.com>
    <mailto:sip_user@example.com <mailto:sip_user@example.com>>> – SIP user.
    > >
    > > xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    <mailto:xcap_user@xcap.example.com <mailto:xcap_user@xcap.example.com>>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>> – XCAP user.
    > >
    > > 2.2 The same users:
    > >
    > > user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>
    > <mailto:user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>> – SIP user.
    > >
    > > user@xcap.example.com <mailto:user@xcap.example.com>
    <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>
    > <mailto:user@xcap.example.com <mailto:user@xcap.example.com>
    <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>> – XCAP
    > user.
    >
    > SIP Communicator's behaviour in such cases is to assume the
    most common
    > option and allow users to override it when creating their
    accounts. This
    > means that you would need to add the options in the SIP
    account wizard,
    > in either the advanced tab, if there are only a few, or in a
    separate
    > tab, if you think more are necessary.
    >
    > > What is the correct point?
    > >
    > > 3. When REGISTRAR is failed user still has opportunity to
    create
    > > groups/contacts. Is it correct?
    >
    > I am not sure I understand the question. Are you saying that
    users are
    > able to create groups in SIP accounts that are not registered and
    > wondering whether this is correct, or, are you asking whether
    you should
    > allow users to create groups and add contacts to their XCAP
    account even
    > when their SIP account is not registered?
    >
    > > 4. Can someone tell me how contact group creation is
    designed?
    > First
    > > only MetaContactGroup is created, then if user want to
    create
    > > contact inside it - this group created as protocol
    specific
    > group.
    > > Am I right or did I miss something?
    >
    > Exactly.
    >
    > > 5. I think next week I will have something to check in,
    can someone
    > > help me to configure SVN branch?
    >
    > Yes, there is one now (gsoc10/sc-xcap) but you'll only have the
    > possibility to check it out. I would need to have your
    java.net <http://java.net>
    > <http://java.net> user
    > name (as per my off-list mail) in order to give you write
    access to it.
    >
    > > Which SVN client is better to use?
    >
    > That's really a personal preference. Some of the developers
    prefer using
    > the client integrated in the IDE, others go for the command
    line, others
    > yet use git, etc. It's up to you really. Pick the option that
    you are
    > most comfortable with at this point. You can always change
    later if you
    > are in the mood for experimenting.
    >
    > Cheers,
    > Emil
    > >
    > > Thanks, Grigorii
    > >
    > >
    > > 7 мая 2010 г. 13:58 пользователь Emil Ivov
    > <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>> написал:
    > >
    > > Hey Grigorii,
    > >
    > > На 07.05.10 11:30, Grigorii Balutsel написа:
    > > > Hi,
    > > >
    > > > I've implemented basic get/put/delete operation with XCAP
    > server,
    > > added
    > > > support of resource-lists and xcap-caps functionality.
    > >
    > > Way to go! That's a great start!
    > >
    > > > Now I'm trying to integrate it into Sip Communicator,
    could
    > you please
    > > > tell me which things need to be synchronized?
    > > > I've take a look into another protocol implementation and
    > noticed that
    > > > only serverStoredGroupListeners is synchronized.
    > > > All other operations with ContactGroup and Contact are not
    > > synchronized
    > > > and only events are fired - is it correct or I've missed
    > something ?
    > >
    > > Well access to listeners does indeed need to be synced but
    > that's fairly
    > > trivial. The rest is really protocol dependent and therefore
    > up to you.
    > > Imagine for example, that you are looping over a list of
    > objects in the
    > > bundle start thread. If it is important for you to prevent
    > others (e.g.
    > > events originating in the jain-sip and xcap threads) to mess
    > with your
    > > list during that time, then you sync. If you think
    there's no
    > way for
    > > this to happen or if you believe it won't be a problem then
    > you don't.
    > >
    > > It could probably even make sense to postpone the reflection
    > for a time
    > > where you know what situations are possible to occur in your
    > > implementation.
    > >
    > > Hope this helps,
    > > Emil
    > > >
    > > > Thanks, Grigorii
    > > >
    > > > 2010/5/1 Emil Ivov <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>>
    > > >
    > > > Hey folks,
    > > >
    > > > На 01.05.10 12:22, Werner Dittmann написа:
    > > > > 1) I'll check 4285 again to see what are the
    pros/cons of
    > > partial
    > > > > operation and if it is necessary to have this
    in a
    > first
    > > step.
    > > > >
    > > > > 2) need to make up my mind first :slight_smile:
    > > >
    > > > Yes, we should probably discuss these. At the end
    of the
    > day,
    > > what we
    > > > really need here is:
    > > >
    > > > 1. Make our SIP protocol provider retrieve
    contacts from the
    > > server just
    > > > as most protocol would.
    > > > 2. Make sure that what we implement works with popular
    > > deployments and
    > > > server implementations of XCAP but only for the
    contact list
    > > storage use
    > > > case (and I don't think there's an awful lot of them).
    > > >
    > > > Supporting authorization policies is therefore also an
    > > important part,
    > > > although probably not the one with the highest
    priority.
    > Could
    > > keep it
    > > > for after we have a first working implementation.
    > > >
    > > > >> 3. How XCAP layer should look like?
    > > > >> It has to be abstract as much as possible (it will
    > provides all
    > > > >> functionality through interfaces and events, will
    > contain all
    > > > validation,
    > > > >> updating logic and so on)
    > > >
    > > > Well that's kind of the purpose of our operation
    sets so I
    > > don't think
    > > > we'd need to introduce another abstraction layer
    here. This
    > > doesn't mean
    > > > you would have to dump all the code in
    > > ServerStoredContactListSipImpl,
    > > > of course.
    > > >
    > > > You could still add an xcap package in
    impl.protocol.sip and
    > > implement
    > > > utility classes in there but they should be built for
    > > > ServerStoredContactListSipImpl rather than a
    generic use
    > of XCAP.
    > > >
    > > > Cheers,
    > > > Emil
    > > >
    > > >
    > > >
    > >
    >
    ---------------------------------------------------------------------
    > > > To unsubscribe, e-mail:
    > > > dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
    > > >
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>
    > > > For additional commands, e-mail:
    > > > dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>
    > > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>>
    > > >
    > > >
    > >
    > > --
    > > Emil Ivov, Ph.D. 67000
    Strasbourg,
    > > Project Lead France
    > > SIP Communicator
    > > emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>>
    > > PHONE: +33.1.77.62.43.30
    > > http://sip-communicator.org FAX:
    > +33.1.77.62.47.31
    > >
    > >
    >
    > --
    > Emil Ivov, Ph.D. 67000 Strasbourg,
    > Project Lead France
    > SIP Communicator
    > emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > PHONE: +33.1.77.62.43.30
    > http://sip-communicator.org FAX:
    +33.1.77.62.47.31
    >
    >

    --
    Emil Ivov, Ph.D. 67000 Strasbourg,
    Project Lead France
    SIP Communicator
    emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
                  PHONE: +33.1.77.62.43.30
    http://sip-communicator.org FAX: +33.1.77.62.47.31

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#14

Hello Emil,

Can you please help me to resolve the following problem:
I create group "friends" on the XCAP server. Then I create the same group in
SIP Communicator (it doesn't contains any contact), and log in - now there
are two groups with the same name. Is it correct?
If it's correct - how to detect which group belongs to provider?
If I try to add XCAP contact to the second (locally saved) group - it will
try to create the XCAP group and will have exception as this group already
exists.
If its a known issue I will not pay attention to it.

Thanks, Grigorii

···

2010/5/19 Emil Ivov <emcho@sip-communicator.org>

На 19.05.10 13:45, Grigorii Balutsel написа:
> Hello Emil,
>
> It sounds good, so for now I'll add the following:
> When register is called and SIP successfully connected I will try to
> connect to XCAP server, if it is failed - I will only log it. When user
> will try to add some contact/group I will throw
> OperationFailedException.NOT_FOUND.

Doesn't sound like a good idea as it would make presence unusable for
providers that don't have XCAP (i.e. almost all). If XCAP fails in the
beginning, then everything should work as it currently does. The
MetaContactListService would take care of storing the contacts locally.

> Can you please tell me how to add specific libraries into the project?
> I've added specific lines into felix.client.run.properties:
>
> felix.auto.start.85= \
> reference:file:lib/bundle/httpclient-4.0.1.jar \
> reference:file:lib/bundle/httpcore-4.0.1.jar \
> reference:file:lib/bundle/httpmime-4.0.1.jar

There's already an httpcore bundle in SC. Is there any reason you are
not using that one?

Something else. With httpcore, we store the original jar in
lib/installer-excldue and then convert it into a bundle with the
bundle-httpcore target in the build.xml. You can use that as an example
for the other two libs.

> but when I run it I still have java.lang.NoClassDefFoundError:
> org/apache/http/auth/Credentials
> If I put them (files inside libraries) into protocol-sip.jar everything
> works fine.

Notice the Export-Package attribute that bundle-httpcore adds to the
httpcore.jar. You'd need this in order to tell felix what packages in
your bundle are to be made available for others.

Hope this helps,

Emil
>
> Thanks, Grigorii
>
>
> 2010/5/19 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
>
> Hey Grigorii,
>
> На 18.05.10 16:25, Grigorii Balutsel написа:
> > Hello,
> >
> > I have some question:
> >
> > How to say to the user that during login SIP connection is OK, but
> XCAP
> > connection is failed?
> >
> > I've found that ProtocolProviderService has method register if I
put
> > XCAP connect there and if it is failed it will mean that SIP
> connection
> > is failed too.
>
> That's a good question (and I guess, one of the many joys when trying
to
> do presence with SIP :slight_smile: ).
>
> The reason this is tricky is that we don't really know whether XCAP
was
> supposed to be working or not. Since we can't expect users to always
> manually configure their XCAP servers we'll be trying to auto detect
it
> (and that would probably mean a blind stab).
>
> Therefore it would probably be best to handle failures by silently
> logging them and without bothering the user. We may try to refine
this
> later on.
>
> How does this sound?
>
> Cheers,
> Emil
> >
> > Thanks, Grigorii
> >
> >
> > 2010/5/15 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>
> >
> > Hey Grigorii,
> >
> > На 14.05.10 16:07, Grigorii Balutsel написа:
> > > Hello,
> > >
> > > During this week I've almost added support of XCap groups
> into Sip
> > > Communicator.
> >
> > Very glad to hear this! Way to go! :slight_smile:
> >
> > > I've found some things that need to be resolved:
> > >
> > > 1. I didn't find appropriate way how to detect that XCAP
> server
> > > doesn't support partial update. According to RFC
server
> > > capabilities should be written in xcap-caps but all
tested
> > servers
> > > that support partial updated don't write anything. The
> only
> > > solution I've found - try to use partial update
operation,
> > if it's
> > > failed with special HTTP code (Unsupported) remember
> it and use
> > > full update operation in the future.
> > > 2. SIP and XCAP users can be different.
> > >
> > > 2.1 Different users:
> > >
> > > sip_user@example.com <mailto:sip_user@example.com>
> <mailto:sip_user@example.com <mailto:sip_user@example.com>>
> > <mailto:sip_user@example.com <mailto:sip_user@example.com>
> <mailto:sip_user@example.com <mailto:sip_user@example.com>>> - SIP
user.
> > >
> > > xcap_user@xcap.example.com
> <mailto:xcap_user@xcap.example.com>
> <mailto:xcap_user@xcap.example.com <mailto:
xcap_user@xcap.example.com>>
> > <mailto:xcap_user@xcap.example.com
> <mailto:xcap_user@xcap.example.com>
> > <mailto:xcap_user@xcap.example.com
> <mailto:xcap_user@xcap.example.com>>> - XCAP user.
> > >
> > > 2.2 The same users:
> > >
> > > user@example.com <mailto:user@example.com>
> <mailto:user@example.com <mailto:user@example.com>>
> > <mailto:user@example.com <mailto:user@example.com>
> <mailto:user@example.com <mailto:user@example.com>>> - SIP user.
> > >
> > > user@xcap.example.com <mailto:user@xcap.example.com>
> <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>
> > <mailto:user@xcap.example.com <mailto:user@xcap.example.com>
> <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>> -
XCAP
> > user.
> >
> > SIP Communicator's behaviour in such cases is to assume the
> most common
> > option and allow users to override it when creating their
> accounts. This
> > means that you would need to add the options in the SIP
> account wizard,
> > in either the advanced tab, if there are only a few, or in a
> separate
> > tab, if you think more are necessary.
> >
> > > What is the correct point?
> > >
> > > 3. When REGISTRAR is failed user still has opportunity to
> create
> > > groups/contacts. Is it correct?
> >
> > I am not sure I understand the question. Are you saying that
> users are
> > able to create groups in SIP accounts that are not registered
and
> > wondering whether this is correct, or, are you asking whether
> you should
> > allow users to create groups and add contacts to their XCAP
> account even
> > when their SIP account is not registered?
> >
> > > 4. Can someone tell me how contact group creation is
> designed?
> > First
> > > only MetaContactGroup is created, then if user want to
> create
> > > contact inside it - this group created as protocol
> specific
> > group.
> > > Am I right or did I miss something?
> >
> > Exactly.
> >
> > > 5. I think next week I will have something to check in,
> can someone
> > > help me to configure SVN branch?
> >
> > Yes, there is one now (gsoc10/sc-xcap) but you'll only have the
> > possibility to check it out. I would need to have your
> java.net <http://java.net>
> > <http://java.net> user
> > name (as per my off-list mail) in order to give you write
> access to it.
> >
> > > Which SVN client is better to use?
> >
> > That's really a personal preference. Some of the developers
> prefer using
> > the client integrated in the IDE, others go for the command
> line, others
> > yet use git, etc. It's up to you really. Pick the option that
> you are
> > most comfortable with at this point. You can always change
> later if you
> > are in the mood for experimenting.
> >
> > Cheers,
> > Emil
> > >
> > > Thanks, Grigorii
> > >
> > >
> > > 7 мая 2010 г. 13:58 пользователь Emil Ivov
> > <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org <mailto:
emcho@sip-communicator.org>>
> > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>> написал:
> > >
> > > Hey Grigorii,
> > >
> > > На 07.05.10 11:30, Grigorii Balutsel написа:
> > > > Hi,
> > > >
> > > > I've implemented basic get/put/delete operation with
XCAP
> > server,
> > > added
> > > > support of resource-lists and xcap-caps functionality.
> > >
> > > Way to go! That's a great start!
> > >
> > > > Now I'm trying to integrate it into Sip Communicator,
> could
> > you please
> > > > tell me which things need to be synchronized?
> > > > I've take a look into another protocol implementation
and
> > noticed that
> > > > only serverStoredGroupListeners is synchronized.
> > > > All other operations with ContactGroup and Contact are
not
> > > synchronized
> > > > and only events are fired - is it correct or I've
missed
> > something ?
> > >
> > > Well access to listeners does indeed need to be synced
but
> > that's fairly
> > > trivial. The rest is really protocol dependent and
therefore
> > up to you.
> > > Imagine for example, that you are looping over a list of
> > objects in the
> > > bundle start thread. If it is important for you to
prevent
> > others (e.g.
> > > events originating in the jain-sip and xcap threads) to
mess
> > with your
> > > list during that time, then you sync. If you think
> there's no
> > way for
> > > this to happen or if you believe it won't be a problem
then
> > you don't.
> > >
> > > It could probably even make sense to postpone the
reflection
> > for a time
> > > where you know what situations are possible to occur in
your
> > > implementation.
> > >
> > > Hope this helps,
> > > Emil
> > > >
> > > > Thanks, Grigorii
> > > >
> > > > 2010/5/1 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>
> > > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>>>
> > > >
> > > > Hey folks,
> > > >
> > > > На 01.05.10 12:22, Werner Dittmann написа:
> > > > > 1) I'll check 4285 again to see what are the
> pros/cons of
> > > partial
> > > > > operation and if it is necessary to have this
> in a
> > first
> > > step.
> > > > >
> > > > > 2) need to make up my mind first :slight_smile:
> > > >
> > > > Yes, we should probably discuss these. At the end
> of the
> > day,
> > > what we
> > > > really need here is:
> > > >
> > > > 1. Make our SIP protocol provider retrieve
> contacts from the
> > > server just
> > > > as most protocol would.
> > > > 2. Make sure that what we implement works with
popular
> > > deployments and
> > > > server implementations of XCAP but only for the
> contact list
> > > storage use
> > > > case (and I don't think there's an awful lot of
them).
> > > >
> > > > Supporting authorization policies is therefore also
an
> > > important part,
> > > > although probably not the one with the highest
> priority.
> > Could
> > > keep it
> > > > for after we have a first working implementation.
> > > >
> > > > >> 3. How XCAP layer should look like?
> > > > >> It has to be abstract as much as possible (it
will
> > provides all
> > > > >> functionality through interfaces and events,
will
> > contain all
> > > > validation,
> > > > >> updating logic and so on)
> > > >
> > > > Well that's kind of the purpose of our operation
> sets so I
> > > don't think
> > > > we'd need to introduce another abstraction layer
> here. This
> > > doesn't mean
> > > > you would have to dump all the code in
> > > ServerStoredContactListSipImpl,
> > > > of course.
> > > >
> > > > You could still add an xcap package in
> impl.protocol.sip and
> > > implement
> > > > utility classes in there but they should be built
for
> > > > ServerStoredContactListSipImpl rather than a
> generic use
> > of XCAP.
> > > >
> > > > Cheers,
> > > > Emil
> > > >
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > > dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
> > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
> > > >
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
> > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>
> > > > For additional commands, e-mail:
> > > > dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>
> > > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>>
> > > > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>
> > > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>>>
> > > >
> > > >
> > >
> > > --
> > > Emil Ivov, Ph.D. 67000
> Strasbourg,
> > > Project Lead France
> > > SIP Communicator
> > > emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org <mailto:
emcho@sip-communicator.org>>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org <mailto:
emcho@sip-communicator.org>>>
> > > PHONE: +33.1.77.62.43.30
> > > http://sip-communicator.org FAX:
> > +33.1.77.62.47.31
> > >
> > >
> >
> > --
> > Emil Ivov, Ph.D. 67000
Strasbourg,
> > Project Lead France
> > SIP Communicator
> > emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org <mailto:
emcho@sip-communicator.org>>
> > PHONE: +33.1.77.62.43.30
> > http://sip-communicator.org FAX:
> +33.1.77.62.47.31
> >
> >
>
> --
> Emil Ivov, Ph.D. 67000 Strasbourg,
> Project Lead France
> SIP Communicator
> emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> PHONE: +33.1.77.62.43.30
> http://sip-communicator.org FAX:
+33.1.77.62.47.31
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31


#15

Hey Grigorii,

На 20.05.10 15:30, Grigorii Balutsel написа:

Hello Emil,

Can you please help me to resolve the following problem:
I create group "friends" on the XCAP server. Then I create the same
group in SIP Communicator (it doesn't contains any contact), and log in
- now there are two groups with the same name. Is it correct?

Doesn't sound so.

If it's correct - how to detect which group belongs to provider?
If I try to add XCAP contact to the second (locally saved) group - it
will try to create the XCAP group and will have exception as this group
already exists.
If its a known issue I will not pay attention to it.

Here's what's supposed to happen. When you launch SC, the
MetaContactListService will tell you (i.e. the SIP presence op set) what
groups it knows about via the createUnresolvedGroup. Next, when you
actually connect to the XCAP service and retrieve the groups (or in case
you have already done this) you would, for every group, check whether
it was reported to you as unresolved.

If it is, then you need to fire a group resovled event. Otherwise you'd
go for a group created event. When firing these, make sure that you set
the parent group properly. In your case this may be the root group for
the protocol, which is often a virtual group that we create locally and
that doesn't have a counterpart on the server.

If you are seeing the "friends" group twice then you are firing events
that are somehow confusing the MCL service into thinking there are two
such groups. Could be an issue with the parent groups.

Cheers,
Emil

···

Thanks, Grigorii

2010/5/19 Emil Ivov <emcho@sip-communicator.org
<mailto:emcho@sip-communicator.org>>

    На 19.05.10 13:45, Grigorii Balutsel написа:
    > Hello Emil,
    >
    > It sounds good, so for now I'll add the following:
    > When register is called and SIP successfully connected I will try to
    > connect to XCAP server, if it is failed - I will only log it. When
    user
    > will try to add some contact/group I will throw
    > OperationFailedException.NOT_FOUND.

    Doesn't sound like a good idea as it would make presence unusable for
    providers that don't have XCAP (i.e. almost all). If XCAP fails in the
    beginning, then everything should work as it currently does. The
    MetaContactListService would take care of storing the contacts locally.

    > Can you please tell me how to add specific libraries into the project?
    > I've added specific lines into felix.client.run.properties:
    >
    > felix.auto.start.85= \
    > reference:file:lib/bundle/httpclient-4.0.1.jar \
    > reference:file:lib/bundle/httpcore-4.0.1.jar \
    > reference:file:lib/bundle/httpmime-4.0.1.jar

    There's already an httpcore bundle in SC. Is there any reason you are
    not using that one?

    Something else. With httpcore, we store the original jar in
    lib/installer-excldue and then convert it into a bundle with the
    bundle-httpcore target in the build.xml. You can use that as an example
    for the other two libs.

    > but when I run it I still have java.lang.NoClassDefFoundError:
    > org/apache/http/auth/Credentials
    > If I put them (files inside libraries) into protocol-sip.jar
    everything
    > works fine.

    Notice the Export-Package attribute that bundle-httpcore adds to the
    httpcore.jar. You'd need this in order to tell felix what packages in
    your bundle are to be made available for others.

    Hope this helps,

    Emil
    >
    > Thanks, Grigorii
    >
    >
    > 2010/5/19 Emil Ivov <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    >
    > Hey Grigorii,
    >
    > На 18.05.10 16:25, Grigorii Balutsel написа:
    > > Hello,
    > >
    > > I have some question:
    > >
    > > How to say to the user that during login SIP connection is
    OK, but
    > XCAP
    > > connection is failed?
    > >
    > > I’ve found that ProtocolProviderService has method register
    if I put
    > > XCAP connect there and if it is failed it will mean that SIP
    > connection
    > > is failed too.
    >
    > That's a good question (and I guess, one of the many joys when
    trying to
    > do presence with SIP :slight_smile: ).
    >
    > The reason this is tricky is that we don't really know whether
    XCAP was
    > supposed to be working or not. Since we can't expect users to
    always
    > manually configure their XCAP servers we'll be trying to auto
    detect it
    > (and that would probably mean a blind stab).
    >
    > Therefore it would probably be best to handle failures by silently
    > logging them and without bothering the user. We may try to
    refine this
    > later on.
    >
    > How does this sound?
    >
    > Cheers,
    > Emil
    > >
    > > Thanks, Grigorii
    > >
    > >
    > > 2010/5/15 Emil Ivov <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>
    > >
    > > Hey Grigorii,
    > >
    > > На 14.05.10 16:07, Grigorii Balutsel написа:
    > > > Hello,
    > > >
    > > > During this week I’ve almost added support of XCap groups
    > into Sip
    > > > Communicator.
    > >
    > > Very glad to hear this! Way to go! :slight_smile:
    > >
    > > > I’ve found some things that need to be resolved:
    > > >
    > > > 1. I didn’t find appropriate way how to detect that
    XCAP
    > server
    > > > doesn’t support partial update. According to
    RFC server
    > > > capabilities should be written in xcap-caps but
    all tested
    > > servers
    > > > that support partial updated don’t write
    anything. The
    > only
    > > > solution I’ve found – try to use partial update
    operation,
    > > if it’s
    > > > failed with special HTTP code (Unsupported) remember
    > it and use
    > > > full update operation in the future.
    > > > 2. SIP and XCAP users can be different.
    > > >
    > > > 2.1 Different users:
    > > >
    > > > sip_user@example.com <mailto:sip_user@example.com>
    <mailto:sip_user@example.com <mailto:sip_user@example.com>>
    > <mailto:sip_user@example.com <mailto:sip_user@example.com>
    <mailto:sip_user@example.com <mailto:sip_user@example.com>>>
    > > <mailto:sip_user@example.com
    <mailto:sip_user@example.com> <mailto:sip_user@example.com
    <mailto:sip_user@example.com>>
    > <mailto:sip_user@example.com <mailto:sip_user@example.com>
    <mailto:sip_user@example.com <mailto:sip_user@example.com>>>> – SIP
    user.
    > > >
    > > > xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    <mailto:xcap_user@xcap.example.com <mailto:xcap_user@xcap.example.com>>>
    > > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>
    > > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>>> – XCAP user.
    > > >
    > > > 2.2 The same users:
    > > >
    > > > user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>
    > <mailto:user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>>
    > > <mailto:user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>
    > <mailto:user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>>> – SIP user.
    > > >
    > > > user@xcap.example.com <mailto:user@xcap.example.com>
    <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>
    > <mailto:user@xcap.example.com <mailto:user@xcap.example.com>
    <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>>
    > > <mailto:user@xcap.example.com
    <mailto:user@xcap.example.com> <mailto:user@xcap.example.com
    <mailto:user@xcap.example.com>>
    > <mailto:user@xcap.example.com <mailto:user@xcap.example.com>
    <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>>> – XCAP
    > > user.
    > >
    > > SIP Communicator's behaviour in such cases is to assume the
    > most common
    > > option and allow users to override it when creating their
    > accounts. This
    > > means that you would need to add the options in the SIP
    > account wizard,
    > > in either the advanced tab, if there are only a few, or in a
    > separate
    > > tab, if you think more are necessary.
    > >
    > > > What is the correct point?
    > > >
    > > > 3. When REGISTRAR is failed user still has
    opportunity to
    > create
    > > > groups/contacts. Is it correct?
    > >
    > > I am not sure I understand the question. Are you saying that
    > users are
    > > able to create groups in SIP accounts that are not
    registered and
    > > wondering whether this is correct, or, are you asking
    whether
    > you should
    > > allow users to create groups and add contacts to their XCAP
    > account even
    > > when their SIP account is not registered?
    > >
    > > > 4. Can someone tell me how contact group creation is
    > designed?
    > > First
    > > > only MetaContactGroup is created, then if user
    want to
    > create
    > > > contact inside it - this group created as protocol
    > specific
    > > group.
    > > > Am I right or did I miss something?
    > >
    > > Exactly.
    > >
    > > > 5. I think next week I will have something to check in,
    > can someone
    > > > help me to configure SVN branch?
    > >
    > > Yes, there is one now (gsoc10/sc-xcap) but you'll only
    have the
    > > possibility to check it out. I would need to have your
    > java.net <http://java.net> <http://java.net>
    > > <http://java.net> user
    > > name (as per my off-list mail) in order to give you write
    > access to it.
    > >
    > > > Which SVN client is better to use?
    > >
    > > That's really a personal preference. Some of the developers
    > prefer using
    > > the client integrated in the IDE, others go for the command
    > line, others
    > > yet use git, etc. It's up to you really. Pick the option
    that
    > you are
    > > most comfortable with at this point. You can always change
    > later if you
    > > are in the mood for experimenting.
    > >
    > > Cheers,
    > > Emil
    > > >
    > > > Thanks, Grigorii
    > > >
    > > >
    > > > 7 мая 2010 г. 13:58 пользователь Emil Ivov
    > > <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>>
    > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>> написал:
    > > >
    > > > Hey Grigorii,
    > > >
    > > > На 07.05.10 11:30, Grigorii Balutsel написа:
    > > > > Hi,
    > > > >
    > > > > I've implemented basic get/put/delete operation
    with XCAP
    > > server,
    > > > added
    > > > > support of resource-lists and xcap-caps
    functionality.
    > > >
    > > > Way to go! That's a great start!
    > > >
    > > > > Now I'm trying to integrate it into Sip
    Communicator,
    > could
    > > you please
    > > > > tell me which things need to be synchronized?
    > > > > I've take a look into another protocol
    implementation and
    > > noticed that
    > > > > only serverStoredGroupListeners is synchronized.
    > > > > All other operations with ContactGroup and
    Contact are not
    > > > synchronized
    > > > > and only events are fired - is it correct or
    I've missed
    > > something ?
    > > >
    > > > Well access to listeners does indeed need to be
    synced but
    > > that's fairly
    > > > trivial. The rest is really protocol dependent and
    therefore
    > > up to you.
    > > > Imagine for example, that you are looping over a
    list of
    > > objects in the
    > > > bundle start thread. If it is important for you to
    prevent
    > > others (e.g.
    > > > events originating in the jain-sip and xcap
    threads) to mess
    > > with your
    > > > list during that time, then you sync. If you think
    > there's no
    > > way for
    > > > this to happen or if you believe it won't be a
    problem then
    > > you don't.
    > > >
    > > > It could probably even make sense to postpone the
    reflection
    > > for a time
    > > > where you know what situations are possible to
    occur in your
    > > > implementation.
    > > >
    > > > Hope this helps,
    > > > Emil
    > > > >
    > > > > Thanks, Grigorii
    > > > >
    > > > > 2010/5/1 Emil Ivov <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>
    > > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>>>
    > > > >
    > > > > Hey folks,
    > > > >
    > > > > На 01.05.10 12:22, Werner Dittmann написа:
    > > > > > 1) I'll check 4285 again to see what are the
    > pros/cons of
    > > > partial
    > > > > > operation and if it is necessary to
    have this
    > in a
    > > first
    > > > step.
    > > > > >
    > > > > > 2) need to make up my mind first :slight_smile:
    > > > >
    > > > > Yes, we should probably discuss these. At
    the end
    > of the
    > > day,
    > > > what we
    > > > > really need here is:
    > > > >
    > > > > 1. Make our SIP protocol provider retrieve
    > contacts from the
    > > > server just
    > > > > as most protocol would.
    > > > > 2. Make sure that what we implement works
    with popular
    > > > deployments and
    > > > > server implementations of XCAP but only for the
    > contact list
    > > > storage use
    > > > > case (and I don't think there's an awful lot
    of them).
    > > > >
    > > > > Supporting authorization policies is
    therefore also an
    > > > important part,
    > > > > although probably not the one with the highest
    > priority.
    > > Could
    > > > keep it
    > > > > for after we have a first working
    implementation.
    > > > >
    > > > > >> 3. How XCAP layer should look like?
    > > > > >> It has to be abstract as much as possible
    (it will
    > > provides all
    > > > > >> functionality through interfaces and
    events, will
    > > contain all
    > > > > validation,
    > > > > >> updating logic and so on)
    > > > >
    > > > > Well that's kind of the purpose of our operation
    > sets so I
    > > > don't think
    > > > > we'd need to introduce another abstraction layer
    > here. This
    > > > doesn't mean
    > > > > you would have to dump all the code in
    > > > ServerStoredContactListSipImpl,
    > > > > of course.
    > > > >
    > > > > You could still add an xcap package in
    > impl.protocol.sip and
    > > > implement
    > > > > utility classes in there but they should be
    built for
    > > > > ServerStoredContactListSipImpl rather than a
    > generic use
    > > of XCAP.
    > > > >
    > > > > Cheers,
    > > > > Emil
    > > > >
    > > > >
    > > > >
    > > >
    > >
    >
    ---------------------------------------------------------------------
    > > > > To unsubscribe, e-mail:
    > > > >
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
    > > >
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>
    > > > >
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
    > > >
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>>
    > > > > For additional commands, e-mail:
    > > > > dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>
    > > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>>
    > > > >
    <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>
    > > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>>>
    > > > >
    > > > >
    > > >
    > > > --
    > > > Emil Ivov, Ph.D. 67000
    > Strasbourg,
    > > > Project Lead France
    > > > SIP Communicator
    > > > emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>
    > > > PHONE: +33.1.77.62.43.30
    > > > http://sip-communicator.org FAX:
    > > +33.1.77.62.47.31
    > > >
    > > >
    > >
    > > --
    > > Emil Ivov, Ph.D. 67000
    Strasbourg,
    > > Project Lead France
    > > SIP Communicator
    > > emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>>
    > > PHONE: +33.1.77.62.43.30
    > > http://sip-communicator.org FAX:
    > +33.1.77.62.47.31
    > >
    > >
    >
    > --
    > Emil Ivov, Ph.D. 67000 Strasbourg,
    > Project Lead France
    > SIP Communicator
    > emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > PHONE: +33.1.77.62.43.30
    > http://sip-communicator.org FAX:
    +33.1.77.62.47.31
    >
    >

    --
    Emil Ivov, Ph.D. 67000 Strasbourg,
    Project Lead France
    SIP Communicator
    emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
                  PHONE: +33.1.77.62.43.30
    http://sip-communicator.org FAX: +33.1.77.62.47.31

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#16

Hello,

I've almost completed adding XCAP functionality inside SIP Communicator.
I need to resolve only one problem and I will check in my changes - how to
implement rename operation with the contact?
I've found only
OperationSetPersistentPresence.renameServerStoredContactGroup for the group
but there is no such method for the contact. I've found that only MetaGroup
is updated. Am I right?

Thanks, Grigorii.

···

2010/5/20 Emil Ivov <emcho@sip-communicator.org>

Hey Grigorii,

На 20.05.10 15:30, Grigorii Balutsel написа:
> Hello Emil,
>
> Can you please help me to resolve the following problem:
> I create group "friends" on the XCAP server. Then I create the same
> group in SIP Communicator (it doesn't contains any contact), and log in
> - now there are two groups with the same name. Is it correct?

Doesn't sound so.

> If it's correct - how to detect which group belongs to provider?
> If I try to add XCAP contact to the second (locally saved) group - it
> will try to create the XCAP group and will have exception as this group
> already exists.
> If its a known issue I will not pay attention to it.

Here's what's supposed to happen. When you launch SC, the
MetaContactListService will tell you (i.e. the SIP presence op set) what
groups it knows about via the createUnresolvedGroup. Next, when you
actually connect to the XCAP service and retrieve the groups (or in case
you have already done this) you would, for every group, check whether
it was reported to you as unresolved.

If it is, then you need to fire a group resovled event. Otherwise you'd
go for a group created event. When firing these, make sure that you set
the parent group properly. In your case this may be the root group for
the protocol, which is often a virtual group that we create locally and
that doesn't have a counterpart on the server.

If you are seeing the "friends" group twice then you are firing events
that are somehow confusing the MCL service into thinking there are two
such groups. Could be an issue with the parent groups.

Cheers,
Emil
>
> Thanks, Grigorii
>
> 2010/5/19 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
>
> На 19.05.10 13:45, Grigorii Balutsel написа:
> > Hello Emil,
> >
> > It sounds good, so for now I'll add the following:
> > When register is called and SIP successfully connected I will try
to
> > connect to XCAP server, if it is failed - I will only log it. When
> user
> > will try to add some contact/group I will throw
> > OperationFailedException.NOT_FOUND.
>
> Doesn't sound like a good idea as it would make presence unusable for
> providers that don't have XCAP (i.e. almost all). If XCAP fails in
the
> beginning, then everything should work as it currently does. The
> MetaContactListService would take care of storing the contacts
locally.
>
> > Can you please tell me how to add specific libraries into the
project?
> > I've added specific lines into felix.client.run.properties:
> >
> > felix.auto.start.85= \
> > reference:file:lib/bundle/httpclient-4.0.1.jar \
> > reference:file:lib/bundle/httpcore-4.0.1.jar \
> > reference:file:lib/bundle/httpmime-4.0.1.jar
>
> There's already an httpcore bundle in SC. Is there any reason you are
> not using that one?
>
> Something else. With httpcore, we store the original jar in
> lib/installer-excldue and then convert it into a bundle with the
> bundle-httpcore target in the build.xml. You can use that as an
example
> for the other two libs.
>
> > but when I run it I still have java.lang.NoClassDefFoundError:
> > org/apache/http/auth/Credentials
> > If I put them (files inside libraries) into protocol-sip.jar
> everything
> > works fine.
>
> Notice the Export-Package attribute that bundle-httpcore adds to the
> httpcore.jar. You'd need this in order to tell felix what packages in
> your bundle are to be made available for others.
>
> Hope this helps,
>
> Emil
> >
> > Thanks, Grigorii
> >
> >
> > 2010/5/19 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>
> >
> > Hey Grigorii,
> >
> > На 18.05.10 16:25, Grigorii Balutsel написа:
> > > Hello,
> > >
> > > I have some question:
> > >
> > > How to say to the user that during login SIP connection is
> OK, but
> > XCAP
> > > connection is failed?
> > >
> > > I've found that ProtocolProviderService has method register
> if I put
> > > XCAP connect there and if it is failed it will mean that SIP
> > connection
> > > is failed too.
> >
> > That's a good question (and I guess, one of the many joys when
> trying to
> > do presence with SIP :slight_smile: ).
> >
> > The reason this is tricky is that we don't really know whether
> XCAP was
> > supposed to be working or not. Since we can't expect users to
> always
> > manually configure their XCAP servers we'll be trying to auto
> detect it
> > (and that would probably mean a blind stab).
> >
> > Therefore it would probably be best to handle failures by
silently
> > logging them and without bothering the user. We may try to
> refine this
> > later on.
> >
> > How does this sound?
> >
> > Cheers,
> > Emil
> > >
> > > Thanks, Grigorii
> > >
> > >
> > > 2010/5/15 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>>
> > >
> > > Hey Grigorii,
> > >
> > > На 14.05.10 16:07, Grigorii Balutsel написа:
> > > > Hello,
> > > >
> > > > During this week I've almost added support of XCap
groups
> > into Sip
> > > > Communicator.
> > >
> > > Very glad to hear this! Way to go! :slight_smile:
> > >
> > > > I've found some things that need to be resolved:
> > > >
> > > > 1. I didn't find appropriate way how to detect that
> XCAP
> > server
> > > > doesn't support partial update. According to
> RFC server
> > > > capabilities should be written in xcap-caps but
> all tested
> > > servers
> > > > that support partial updated don't write
> anything. The
> > only
> > > > solution I've found - try to use partial update
> operation,
> > > if it's
> > > > failed with special HTTP code (Unsupported)
remember
> > it and use
> > > > full update operation in the future.
> > > > 2. SIP and XCAP users can be different.
> > > >
> > > > 2.1 Different users:
> > > >
> > > > sip_user@example.com <mailto:sip_user@example.com>
> <mailto:sip_user@example.com <mailto:sip_user@example.com>>
> > <mailto:sip_user@example.com <mailto:sip_user@example.com>
> <mailto:sip_user@example.com <mailto:sip_user@example.com>>>
> > > <mailto:sip_user@example.com
> <mailto:sip_user@example.com> <mailto:sip_user@example.com
> <mailto:sip_user@example.com>>
> > <mailto:sip_user@example.com <mailto:sip_user@example.com>
> <mailto:sip_user@example.com <mailto:sip_user@example.com>>>> - SIP
> user.
> > > >
> > > > xcap_user@xcap.example.com
> <mailto:xcap_user@xcap.example.com>
> > <mailto:xcap_user@xcap.example.com
> <mailto:xcap_user@xcap.example.com>>
> > <mailto:xcap_user@xcap.example.com
> <mailto:xcap_user@xcap.example.com>
> <mailto:xcap_user@xcap.example.com <mailto:
xcap_user@xcap.example.com>>>
> > > <mailto:xcap_user@xcap.example.com
> <mailto:xcap_user@xcap.example.com>
> > <mailto:xcap_user@xcap.example.com
> <mailto:xcap_user@xcap.example.com>>
> > > <mailto:xcap_user@xcap.example.com
> <mailto:xcap_user@xcap.example.com>
> > <mailto:xcap_user@xcap.example.com
> <mailto:xcap_user@xcap.example.com>>>> - XCAP user.
> > > >
> > > > 2.2 The same users:
> > > >
> > > > user@example.com <mailto:user@example.com>
> <mailto:user@example.com <mailto:user@example.com>>
> > <mailto:user@example.com <mailto:user@example.com>
> <mailto:user@example.com <mailto:user@example.com>>>
> > > <mailto:user@example.com <mailto:user@example.com>
> <mailto:user@example.com <mailto:user@example.com>>
> > <mailto:user@example.com <mailto:user@example.com>
> <mailto:user@example.com <mailto:user@example.com>>>> - SIP user.
> > > >
> > > > user@xcap.example.com <mailto:user@xcap.example.com>
> <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>
> > <mailto:user@xcap.example.com <mailto:user@xcap.example.com>
> <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>>
> > > <mailto:user@xcap.example.com
> <mailto:user@xcap.example.com> <mailto:user@xcap.example.com
> <mailto:user@xcap.example.com>>
> > <mailto:user@xcap.example.com <mailto:user@xcap.example.com>
> <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>>> -
XCAP
> > > user.
> > >
> > > SIP Communicator's behaviour in such cases is to assume
the
> > most common
> > > option and allow users to override it when creating their
> > accounts. This
> > > means that you would need to add the options in the SIP
> > account wizard,
> > > in either the advanced tab, if there are only a few, or
in a
> > separate
> > > tab, if you think more are necessary.
> > >
> > > > What is the correct point?
> > > >
> > > > 3. When REGISTRAR is failed user still has
> opportunity to
> > create
> > > > groups/contacts. Is it correct?
> > >
> > > I am not sure I understand the question. Are you saying
that
> > users are
> > > able to create groups in SIP accounts that are not
> registered and
> > > wondering whether this is correct, or, are you asking
> whether
> > you should
> > > allow users to create groups and add contacts to their
XCAP
> > account even
> > > when their SIP account is not registered?
> > >
> > > > 4. Can someone tell me how contact group creation is
> > designed?
> > > First
> > > > only MetaContactGroup is created, then if user
> want to
> > create
> > > > contact inside it - this group created as
protocol
> > specific
> > > group.
> > > > Am I right or did I miss something?
> > >
> > > Exactly.
> > >
> > > > 5. I think next week I will have something to check
in,
> > can someone
> > > > help me to configure SVN branch?
> > >
> > > Yes, there is one now (gsoc10/sc-xcap) but you'll only
> have the
> > > possibility to check it out. I would need to have your
> > java.net <http://java.net> <http://java.net>
> > > <http://java.net> user
> > > name (as per my off-list mail) in order to give you write
> > access to it.
> > >
> > > > Which SVN client is better to use?
> > >
> > > That's really a personal preference. Some of the
developers
> > prefer using
> > > the client integrated in the IDE, others go for the
command
> > line, others
> > > yet use git, etc. It's up to you really. Pick the option
> that
> > you are
> > > most comfortable with at this point. You can always
change
> > later if you
> > > are in the mood for experimenting.
> > >
> > > Cheers,
> > > Emil
> > > >
> > > > Thanks, Grigorii
> > > >
> > > >
> > > > 7 мая 2010 г. 13:58 пользователь Emil Ivov
> > > <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org <mailto:
emcho@sip-communicator.org>>>
> > > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>>> написал:
> > > >
> > > > Hey Grigorii,
> > > >
> > > > На 07.05.10 11:30, Grigorii Balutsel написа:
> > > > > Hi,
> > > > >
> > > > > I've implemented basic get/put/delete operation
> with XCAP
> > > server,
> > > > added
> > > > > support of resource-lists and xcap-caps
> functionality.
> > > >
> > > > Way to go! That's a great start!
> > > >
> > > > > Now I'm trying to integrate it into Sip
> Communicator,
> > could
> > > you please
> > > > > tell me which things need to be synchronized?
> > > > > I've take a look into another protocol
> implementation and
> > > noticed that
> > > > > only serverStoredGroupListeners is synchronized.
> > > > > All other operations with ContactGroup and
> Contact are not
> > > > synchronized
> > > > > and only events are fired - is it correct or
> I've missed
> > > something ?
> > > >
> > > > Well access to listeners does indeed need to be
> synced but
> > > that's fairly
> > > > trivial. The rest is really protocol dependent and
> therefore
> > > up to you.
> > > > Imagine for example, that you are looping over a
> list of
> > > objects in the
> > > > bundle start thread. If it is important for you to
> prevent
> > > others (e.g.
> > > > events originating in the jain-sip and xcap
> threads) to mess
> > > with your
> > > > list during that time, then you sync. If you think
> > there's no
> > > way for
> > > > this to happen or if you believe it won't be a
> problem then
> > > you don't.
> > > >
> > > > It could probably even make sense to postpone the
> reflection
> > > for a time
> > > > where you know what situations are possible to
> occur in your
> > > > implementation.
> > > >
> > > > Hope this helps,
> > > > Emil
> > > > >
> > > > > Thanks, Grigorii
> > > > >
> > > > > 2010/5/1 Emil Ivov <emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>
> > > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>>
> > > > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>
> > > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>>>>
> > > > >
> > > > > Hey folks,
> > > > >
> > > > > На 01.05.10 12:22, Werner Dittmann написа:
> > > > > > 1) I'll check 4285 again to see what are
the
> > pros/cons of
> > > > partial
> > > > > > operation and if it is necessary to
> have this
> > in a
> > > first
> > > > step.
> > > > > >
> > > > > > 2) need to make up my mind first :slight_smile:
> > > > >
> > > > > Yes, we should probably discuss these. At
> the end
> > of the
> > > day,
> > > > what we
> > > > > really need here is:
> > > > >
> > > > > 1. Make our SIP protocol provider retrieve
> > contacts from the
> > > > server just
> > > > > as most protocol would.
> > > > > 2. Make sure that what we implement works
> with popular
> > > > deployments and
> > > > > server implementations of XCAP but only for
the
> > contact list
> > > > storage use
> > > > > case (and I don't think there's an awful lot
> of them).
> > > > >
> > > > > Supporting authorization policies is
> therefore also an
> > > > important part,
> > > > > although probably not the one with the
highest
> > priority.
> > > Could
> > > > keep it
> > > > > for after we have a first working
> implementation.
> > > > >
> > > > > >> 3. How XCAP layer should look like?
> > > > > >> It has to be abstract as much as possible
> (it will
> > > provides all
> > > > > >> functionality through interfaces and
> events, will
> > > contain all
> > > > > validation,
> > > > > >> updating logic and so on)
> > > > >
> > > > > Well that's kind of the purpose of our
operation
> > sets so I
> > > > don't think
> > > > > we'd need to introduce another abstraction
layer
> > here. This
> > > > doesn't mean
> > > > > you would have to dump all the code in
> > > > ServerStoredContactListSipImpl,
> > > > > of course.
> > > > >
> > > > > You could still add an xcap package in
> > impl.protocol.sip and
> > > > implement
> > > > > utility classes in there but they should be
> built for
> > > > > ServerStoredContactListSipImpl rather than a
> > generic use
> > > of XCAP.
> > > > >
> > > > > Cheers,
> > > > > Emil
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > > >
> dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
> > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
> > > >
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
> > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>
> > > > >
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
> > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
> > > >
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
> > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>>
> > > > > For additional commands, e-mail:
> > > > > dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>
> > > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>>
> > > > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>
> > > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>>>
> > > > >
> <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>
> > > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>>
> > > > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>
> > > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
> > <mailto:dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>>>>>
> > > > >
> > > > >
> > > >
> > > > --
> > > > Emil Ivov, Ph.D.
67000
> > Strasbourg,
> > > > Project Lead
France
> > > > SIP Communicator
> > > > emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org <mailto:
emcho@sip-communicator.org>>>
> > > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>>>>
> > > > PHONE: +33.1.77.62.43.30
> > > > http://sip-communicator.org
FAX:
> > > +33.1.77.62.47.31
> > > >
> > > >
> > >
> > > --
> > > Emil Ivov, Ph.D. 67000
> Strasbourg,
> > > Project Lead France
> > > SIP Communicator
> > > emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org <mailto:
emcho@sip-communicator.org>>
> > <mailto:emcho@sip-communicator.org
> <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org <mailto:
emcho@sip-communicator.org>>>
> > > PHONE: +33.1.77.62.43.30
> > > http://sip-communicator.org FAX:
> > +33.1.77.62.47.31
> > >
> > >
> >
> > --
> > Emil Ivov, Ph.D. 67000
Strasbourg,
> > Project Lead France
> > SIP Communicator
> > emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org <mailto:
emcho@sip-communicator.org>>
> > PHONE: +33.1.77.62.43.30
> > http://sip-communicator.org FAX:
> +33.1.77.62.47.31
> >
> >
>
> --
> Emil Ivov, Ph.D. 67000 Strasbourg,
> Project Lead France
> SIP Communicator
> emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> PHONE: +33.1.77.62.43.30
> http://sip-communicator.org FAX:
+33.1.77.62.47.31
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31


#17

Hey,

For the sake of completeness:

Grigorii and I had a quick off-list chat yesterday and I confirmed that
there was currently no way in OperationSetPresence, that allows
reflecting changes of the display name on the server. The
ServerStoredDetails op set could be an option but it's a bit too
convoluted and it's not used by the GUI.

We may try to think of a way to handle this in the second semester but
until then we'll do without.

Cheers,
Emil

На 31.05.10 11:14, Grigorii Balutsel написа:

···

Hello,

I've almost completed adding XCAP functionality inside SIP Communicator.
I need to resolve only one problem and I will check in my changes - how
to implement rename operation with the contact?
I've found only
OperationSetPersistentPresence.renameServerStoredContactGroup for the
group but there is no such method for the contact. I've found that only
MetaGroup is updated. Am I right?

Thanks, Grigorii.

2010/5/20 Emil Ivov <emcho@sip-communicator.org
<mailto:emcho@sip-communicator.org>>

    Hey Grigorii,

    На 20.05.10 15:30, Grigorii Balutsel написа:
    > Hello Emil,
    >
    > Can you please help me to resolve the following problem:
    > I create group "friends" on the XCAP server. Then I create the same
    > group in SIP Communicator (it doesn't contains any contact), and
    log in
    > - now there are two groups with the same name. Is it correct?

    Doesn't sound so.

    > If it's correct - how to detect which group belongs to provider?
    > If I try to add XCAP contact to the second (locally saved) group - it
    > will try to create the XCAP group and will have exception as this
    group
    > already exists.
    > If its a known issue I will not pay attention to it.

    Here's what's supposed to happen. When you launch SC, the
    MetaContactListService will tell you (i.e. the SIP presence op set) what
    groups it knows about via the createUnresolvedGroup. Next, when you
    actually connect to the XCAP service and retrieve the groups (or in case
    you have already done this) you would, for every group, check whether
    it was reported to you as unresolved.

    If it is, then you need to fire a group resovled event. Otherwise you'd
    go for a group created event. When firing these, make sure that you set
    the parent group properly. In your case this may be the root group for
    the protocol, which is often a virtual group that we create locally and
    that doesn't have a counterpart on the server.

    If you are seeing the "friends" group twice then you are firing events
    that are somehow confusing the MCL service into thinking there are two
    such groups. Could be an issue with the parent groups.

    Cheers,
    Emil
    >
    > Thanks, Grigorii
    >
    > 2010/5/19 Emil Ivov <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    >
    > На 19.05.10 13:45, Grigorii Balutsel написа:
    > > Hello Emil,
    > >
    > > It sounds good, so for now I'll add the following:
    > > When register is called and SIP successfully connected I
    will try to
    > > connect to XCAP server, if it is failed - I will only log
    it. When
    > user
    > > will try to add some contact/group I will throw
    > > OperationFailedException.NOT_FOUND.
    >
    > Doesn't sound like a good idea as it would make presence
    unusable for
    > providers that don't have XCAP (i.e. almost all). If XCAP
    fails in the
    > beginning, then everything should work as it currently does. The
    > MetaContactListService would take care of storing the contacts
    locally.
    >
    > > Can you please tell me how to add specific libraries into
    the project?
    > > I've added specific lines into felix.client.run.properties:
    > >
    > > felix.auto.start.85= \
    > > reference:file:lib/bundle/httpclient-4.0.1.jar \
    > > reference:file:lib/bundle/httpcore-4.0.1.jar \
    > > reference:file:lib/bundle/httpmime-4.0.1.jar
    >
    > There's already an httpcore bundle in SC. Is there any reason
    you are
    > not using that one?
    >
    > Something else. With httpcore, we store the original jar in
    > lib/installer-excldue and then convert it into a bundle with the
    > bundle-httpcore target in the build.xml. You can use that as
    an example
    > for the other two libs.
    >
    > > but when I run it I still have java.lang.NoClassDefFoundError:
    > > org/apache/http/auth/Credentials
    > > If I put them (files inside libraries) into protocol-sip.jar
    > everything
    > > works fine.
    >
    > Notice the Export-Package attribute that bundle-httpcore adds
    to the
    > httpcore.jar. You'd need this in order to tell felix what
    packages in
    > your bundle are to be made available for others.
    >
    > Hope this helps,
    >
    > Emil
    > >
    > > Thanks, Grigorii
    > >
    > >
    > > 2010/5/19 Emil Ivov <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>
    > >
    > > Hey Grigorii,
    > >
    > > На 18.05.10 16:25, Grigorii Balutsel написа:
    > > > Hello,
    > > >
    > > > I have some question:
    > > >
    > > > How to say to the user that during login SIP connection is
    > OK, but
    > > XCAP
    > > > connection is failed?
    > > >
    > > > I’ve found that ProtocolProviderService has method
    register
    > if I put
    > > > XCAP connect there and if it is failed it will mean
    that SIP
    > > connection
    > > > is failed too.
    > >
    > > That's a good question (and I guess, one of the many
    joys when
    > trying to
    > > do presence with SIP :slight_smile: ).
    > >
    > > The reason this is tricky is that we don't really know
    whether
    > XCAP was
    > > supposed to be working or not. Since we can't expect
    users to
    > always
    > > manually configure their XCAP servers we'll be trying to
    auto
    > detect it
    > > (and that would probably mean a blind stab).
    > >
    > > Therefore it would probably be best to handle failures
    by silently
    > > logging them and without bothering the user. We may try to
    > refine this
    > > later on.
    > >
    > > How does this sound?
    > >
    > > Cheers,
    > > Emil
    > > >
    > > > Thanks, Grigorii
    > > >
    > > >
    > > > 2010/5/15 Emil Ivov <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>>
    > > >
    > > > Hey Grigorii,
    > > >
    > > > На 14.05.10 16:07, Grigorii Balutsel написа:
    > > > > Hello,
    > > > >
    > > > > During this week I’ve almost added support of
    XCap groups
    > > into Sip
    > > > > Communicator.
    > > >
    > > > Very glad to hear this! Way to go! :slight_smile:
    > > >
    > > > > I’ve found some things that need to be resolved:
    > > > >
    > > > > 1. I didn’t find appropriate way how to
    detect that
    > XCAP
    > > server
    > > > > doesn’t support partial update. According to
    > RFC server
    > > > > capabilities should be written in
    xcap-caps but
    > all tested
    > > > servers
    > > > > that support partial updated don’t write
    > anything. The
    > > only
    > > > > solution I’ve found – try to use partial
    update
    > operation,
    > > > if it’s
    > > > > failed with special HTTP code
    (Unsupported) remember
    > > it and use
    > > > > full update operation in the future.
    > > > > 2. SIP and XCAP users can be different.
    > > > >
    > > > > 2.1 Different users:
    > > > >
    > > > > sip_user@example.com
    <mailto:sip_user@example.com> <mailto:sip_user@example.com
    <mailto:sip_user@example.com>>
    > <mailto:sip_user@example.com <mailto:sip_user@example.com>
    <mailto:sip_user@example.com <mailto:sip_user@example.com>>>
    > > <mailto:sip_user@example.com
    <mailto:sip_user@example.com> <mailto:sip_user@example.com
    <mailto:sip_user@example.com>>
    > <mailto:sip_user@example.com <mailto:sip_user@example.com>
    <mailto:sip_user@example.com <mailto:sip_user@example.com>>>>
    > > > <mailto:sip_user@example.com
    <mailto:sip_user@example.com>
    > <mailto:sip_user@example.com <mailto:sip_user@example.com>>
    <mailto:sip_user@example.com <mailto:sip_user@example.com>
    > <mailto:sip_user@example.com <mailto:sip_user@example.com>>>
    > > <mailto:sip_user@example.com
    <mailto:sip_user@example.com> <mailto:sip_user@example.com
    <mailto:sip_user@example.com>>
    > <mailto:sip_user@example.com <mailto:sip_user@example.com>
    <mailto:sip_user@example.com <mailto:sip_user@example.com>>>>> – SIP
    > user.
    > > > >
    > > > > xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>
    > > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>>
    > > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>>>
    > > > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>
    > > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>>
    > > > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>
    > > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>
    > <mailto:xcap_user@xcap.example.com
    <mailto:xcap_user@xcap.example.com>>>>> – XCAP user.
    > > > >
    > > > > 2.2 The same users:
    > > > >
    > > > > user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>
    > <mailto:user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>>
    > > <mailto:user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>
    > <mailto:user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>>>
    > > > <mailto:user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>
    > <mailto:user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>>
    > > <mailto:user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>
    > <mailto:user@example.com <mailto:user@example.com>
    <mailto:user@example.com <mailto:user@example.com>>>>> – SIP user.
    > > > >
    > > > > user@xcap.example.com
    <mailto:user@xcap.example.com> <mailto:user@xcap.example.com
    <mailto:user@xcap.example.com>>
    > <mailto:user@xcap.example.com <mailto:user@xcap.example.com>
    <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>>
    > > <mailto:user@xcap.example.com
    <mailto:user@xcap.example.com> <mailto:user@xcap.example.com
    <mailto:user@xcap.example.com>>
    > <mailto:user@xcap.example.com <mailto:user@xcap.example.com>
    <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>>>
    > > > <mailto:user@xcap.example.com
    <mailto:user@xcap.example.com>
    > <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>
    <mailto:user@xcap.example.com <mailto:user@xcap.example.com>
    > <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>>
    > > <mailto:user@xcap.example.com
    <mailto:user@xcap.example.com> <mailto:user@xcap.example.com
    <mailto:user@xcap.example.com>>
    > <mailto:user@xcap.example.com <mailto:user@xcap.example.com>
    <mailto:user@xcap.example.com <mailto:user@xcap.example.com>>>>> – XCAP
    > > > user.
    > > >
    > > > SIP Communicator's behaviour in such cases is to
    assume the
    > > most common
    > > > option and allow users to override it when
    creating their
    > > accounts. This
    > > > means that you would need to add the options in
    the SIP
    > > account wizard,
    > > > in either the advanced tab, if there are only a
    few, or in a
    > > separate
    > > > tab, if you think more are necessary.
    > > >
    > > > > What is the correct point?
    > > > >
    > > > > 3. When REGISTRAR is failed user still has
    > opportunity to
    > > create
    > > > > groups/contacts. Is it correct?
    > > >
    > > > I am not sure I understand the question. Are you
    saying that
    > > users are
    > > > able to create groups in SIP accounts that are not
    > registered and
    > > > wondering whether this is correct, or, are you asking
    > whether
    > > you should
    > > > allow users to create groups and add contacts to
    their XCAP
    > > account even
    > > > when their SIP account is not registered?
    > > >
    > > > > 4. Can someone tell me how contact group
    creation is
    > > designed?
    > > > First
    > > > > only MetaContactGroup is created, then if user
    > want to
    > > create
    > > > > contact inside it - this group created as
    protocol
    > > specific
    > > > group.
    > > > > Am I right or did I miss something?
    > > >
    > > > Exactly.
    > > >
    > > > > 5. I think next week I will have something to
    check in,
    > > can someone
    > > > > help me to configure SVN branch?
    > > >
    > > > Yes, there is one now (gsoc10/sc-xcap) but you'll only
    > have the
    > > > possibility to check it out. I would need to have your
    > > java.net <http://java.net> <http://java.net>
    <http://java.net>
    > > > <http://java.net> user
    > > > name (as per my off-list mail) in order to give
    you write
    > > access to it.
    > > >
    > > > > Which SVN client is better to use?
    > > >
    > > > That's really a personal preference. Some of the
    developers
    > > prefer using
    > > > the client integrated in the IDE, others go for
    the command
    > > line, others
    > > > yet use git, etc. It's up to you really. Pick the
    option
    > that
    > > you are
    > > > most comfortable with at this point. You can
    always change
    > > later if you
    > > > are in the mood for experimenting.
    > > >
    > > > Cheers,
    > > > Emil
    > > > >
    > > > > Thanks, Grigorii
    > > > >
    > > > >
    > > > > 7 мая 2010 г. 13:58 пользователь Emil Ivov
    > > > <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>
    > > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>>> написал:
    > > > >
    > > > > Hey Grigorii,
    > > > >
    > > > > На 07.05.10 11:30, Grigorii Balutsel написа:
    > > > > > Hi,
    > > > > >
    > > > > > I've implemented basic get/put/delete
    operation
    > with XCAP
    > > > server,
    > > > > added
    > > > > > support of resource-lists and xcap-caps
    > functionality.
    > > > >
    > > > > Way to go! That's a great start!
    > > > >
    > > > > > Now I'm trying to integrate it into Sip
    > Communicator,
    > > could
    > > > you please
    > > > > > tell me which things need to be synchronized?
    > > > > > I've take a look into another protocol
    > implementation and
    > > > noticed that
    > > > > > only serverStoredGroupListeners is
    synchronized.
    > > > > > All other operations with ContactGroup and
    > Contact are not
    > > > > synchronized
    > > > > > and only events are fired - is it correct or
    > I've missed
    > > > something ?
    > > > >
    > > > > Well access to listeners does indeed need to be
    > synced but
    > > > that's fairly
    > > > > trivial. The rest is really protocol
    dependent and
    > therefore
    > > > up to you.
    > > > > Imagine for example, that you are looping over a
    > list of
    > > > objects in the
    > > > > bundle start thread. If it is important for
    you to
    > prevent
    > > > others (e.g.
    > > > > events originating in the jain-sip and xcap
    > threads) to mess
    > > > with your
    > > > > list during that time, then you sync. If you
    think
    > > there's no
    > > > way for
    > > > > this to happen or if you believe it won't be a
    > problem then
    > > > you don't.
    > > > >
    > > > > It could probably even make sense to
    postpone the
    > reflection
    > > > for a time
    > > > > where you know what situations are possible to
    > occur in your
    > > > > implementation.
    > > > >
    > > > > Hope this helps,
    > > > > Emil
    > > > > >
    > > > > > Thanks, Grigorii
    > > > > >
    > > > > > 2010/5/1 Emil Ivov
    <emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>
    > > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>>
    > > > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>
    > > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>>>>
    > > > > >
    > > > > > Hey folks,
    > > > > >
    > > > > > На 01.05.10 12:22, Werner Dittmann написа:
    > > > > > > 1) I'll check 4285 again to see what
    are the
    > > pros/cons of
    > > > > partial
    > > > > > > operation and if it is necessary to
    > have this
    > > in a
    > > > first
    > > > > step.
    > > > > > >
    > > > > > > 2) need to make up my mind first :slight_smile:
    > > > > >
    > > > > > Yes, we should probably discuss these. At
    > the end
    > > of the
    > > > day,
    > > > > what we
    > > > > > really need here is:
    > > > > >
    > > > > > 1. Make our SIP protocol provider retrieve
    > > contacts from the
    > > > > server just
    > > > > > as most protocol would.
    > > > > > 2. Make sure that what we implement works
    > with popular
    > > > > deployments and
    > > > > > server implementations of XCAP but
    only for the
    > > contact list
    > > > > storage use
    > > > > > case (and I don't think there's an
    awful lot
    > of them).
    > > > > >
    > > > > > Supporting authorization policies is
    > therefore also an
    > > > > important part,
    > > > > > although probably not the one with the
    highest
    > > priority.
    > > > Could
    > > > > keep it
    > > > > > for after we have a first working
    > implementation.
    > > > > >
    > > > > > >> 3. How XCAP layer should look like?
    > > > > > >> It has to be abstract as much as
    possible
    > (it will
    > > > provides all
    > > > > > >> functionality through interfaces and
    > events, will
    > > > contain all
    > > > > > validation,
    > > > > > >> updating logic and so on)
    > > > > >
    > > > > > Well that's kind of the purpose of our
    operation
    > > sets so I
    > > > > don't think
    > > > > > we'd need to introduce another
    abstraction layer
    > > here. This
    > > > > doesn't mean
    > > > > > you would have to dump all the code in
    > > > > ServerStoredContactListSipImpl,
    > > > > > of course.
    > > > > >
    > > > > > You could still add an xcap package in
    > > impl.protocol.sip and
    > > > > implement
    > > > > > utility classes in there but they
    should be
    > built for
    > > > > > ServerStoredContactListSipImpl rather
    than a
    > > generic use
    > > > of XCAP.
    > > > > >
    > > > > > Cheers,
    > > > > > Emil
    > > > > >
    > > > > >
    > > > > >
    > > > >
    > > >
    > >
    >
    ---------------------------------------------------------------------
    > > > > > To unsubscribe, e-mail:
    > > > > >
    > dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
    > > >
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>
    > > > >
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
    > > >
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>>
    > > > > >
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
    > > >
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>
    > > > >
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
    > > >
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>>>
    > > > > > For additional commands, e-mail:
    > > > > > dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>
    > > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>>
    > > > >
    <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>
    > > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>>>
    > > > > >
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>
    > > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>>
    > > > >
    <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>
    > > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    > > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>>>>>
    > > > > >
    > > > > >
    > > > >
    > > > > --
    > > > > Emil Ivov, Ph.D.
      67000
    > > Strasbourg,
    > > > > Project Lead
      France
    > > > > SIP Communicator
    > > > > emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>
    > > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>>
    > > > > PHONE: +33.1.77.62.43.30
    > > > > http://sip-communicator.org
       FAX:
    > > > +33.1.77.62.47.31
    > > > >
    > > > >
    > > >
    > > > --
    > > > Emil Ivov, Ph.D. 67000
    > Strasbourg,
    > > > Project Lead France
    > > > SIP Communicator
    > > > emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>>
    > > > PHONE: +33.1.77.62.43.30
    > > > http://sip-communicator.org FAX:
    > > +33.1.77.62.47.31
    > > >
    > > >
    > >
    > > --
    > > Emil Ivov, Ph.D. 67000
    Strasbourg,
    > > Project Lead France
    > > SIP Communicator
    > > emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>>
    > > PHONE: +33.1.77.62.43.30
    > > http://sip-communicator.org FAX:
    > +33.1.77.62.47.31
    > >
    > >
    >
    > --
    > Emil Ivov, Ph.D. 67000 Strasbourg,
    > Project Lead France
    > SIP Communicator
    > emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > PHONE: +33.1.77.62.43.30
    > http://sip-communicator.org FAX:
    +33.1.77.62.47.31
    >
    >

    --
    Emil Ivov, Ph.D. 67000 Strasbourg,
    Project Lead France
    SIP Communicator
    emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
                  PHONE: +33.1.77.62.43.30
    http://sip-communicator.org FAX: +33.1.77.62.47.31

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net