Scott

All,
Can someone please advise me on the most appropriate strategy for supporting DocShare in both Eclipse 3.4 and Eclipse 3.5 in my plugin? The problem being that in 3.4, the menucontribution comes from an "internal" class


<dynamic class="org.eclipse.ecf.internal.provisional.docshare.menu.DocShareRosterMenuContributionItem"

             id="xxxx">
    </dynamic>

while in 3.5, the classname changes.

Thanks for any direction.

Best,

Marc

while in 3.5, the classname changes.

Thanks for any direction.

Best,

https://bugs.eclipse.org/bugs/show_bug.cgi?id=280347

Thanks,

Scott

Hi,
In p2 I have found an issue when a request is redirected, and the final destination is on another host and requires authentication.

My issue is that I need to get hold of the final destination URL that triggers the HTTP 401, as this is the destination I need to show to the user when prompting for username and password.

So question: How can I detect that filetransfer has been redirected when I get an IncomingFileTransferException with a 401 code?

Scott

Regards
- henrik

Thanks,
Matt

Hi Sither,

This is likely a bug.  Would you please open a bug report for it at:

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=ECF

Thanks Much!

Scott

Sither wrote:

I'm writing an application with a built-in IM tool, and we recently integrated ECF into it. We're currently only using the XMPP provider. ECF has been great so far, but I've been having some minor issues with roster management. When I add a roster entry, the entry shows up twice. Here's what the implementation looks like:

Sender:
(1) Enter contact's username, nickname, and group
(2) Call IRosterSubscriptionSender.sendRosterAdd(username, nickname, new String[] {group});
Receiver:
(3) The subscription request is received via IRosterSubscriptionListener.handleSubscriptionRequest(ID), and the UI displays this and allows the user to accept or reject the request.
(4) Upon clicking "Accept", do two things:
(a) To accept the request, call IPresenceSender.sendPresenceUpdate(sender, new Presence(Type.SUBSCRIBED))
(b) To add the sender to the receiver's roster, call IRosterSubscriptionSender.sendRosterAdd(sender.getName(), null, new String[0]);
Sender:
(5) Upon receiving this subscription request, we automatically respond with SUBSCRIBED

Afterward, the sender correctly shows up once as AVAILABLE in the receiver's roster. But the reicever shows up twice in the sender's roster, once as AVAILABLE and once as UNAVAILABLE. The interesting thing is that the available entry has a resource (not the ECF default, one that we set for our application), but the unavailable copy does not. Because their resources don't match, XMPPID.equals() resolves to false, so somewhere in ECFConnection, both entries are being added separately, but one should actually be updating the original. Does that sound right? After the sender logs out and logs back in, this issue goes away, so this isn't super critical.

I aslo have similar issues with removing roster entries. I haven't figured it out from the source yet, but it seems like there's a small, but elusive, bug in how ECFConnection handles Smack's RosterPackets.

I currently have a workaround for this. I search for and remove invalid roster entries whenever I receive a roster update. Obviously this isn't ideal.

Thanks for the help!

This is likely a bug.  Would you please open a bug report for it at:

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=ECF

Thanks Much!

Scott

I'm writing an application with a built-in IM tool, and we recently integrated ECF into it. We're currently only using the XMPP provider. ECF has been great so far, but I've been having some minor issues with roster management. When I add a roster entry, the entry shows up twice. Here's what the implementation looks like:

Sender:
(1) Enter contact's username, nickname, and group
(2) Call IRosterSubscriptionSender.sendRosterAdd(username, nickname, new String[] {group});
Receiver:
(3) The subscription request is received via IRosterSubscriptionListener.handleSubscriptionRequest(ID), and the UI displays this and allows the user to accept or reject the request.
(4) Upon clicking "Accept", do two things:
(a) To accept the request, call IPresenceSender.sendPresenceUpdate(sender, new Presence(Type.SUBSCRIBED))
(b) To add the sender to the receiver's roster, call IRosterSubscriptionSender.sendRosterAdd(sender.getName(), null, new String[0]);
Sender:
(5) Upon receiving this subscription request, we automatically respond with SUBSCRIBED

Afterward, the sender correctly shows up once as AVAILABLE in the receiver's roster. But the reicever shows up twice in the sender's roster, once as AVAILABLE and once as UNAVAILABLE. The interesting thing is that the available entry has a resource (not the ECF default, one that we set for our application), but the unavailable copy does not. Because their resources don't match, XMPPID.equals() resolves to false, so somewhere in ECFConnection, both entries are being added separately, but one should actually be updating the original. Does that sound right? After the sender logs out and logs back in, this issue goes away, so this isn't super critical.

I aslo have similar issues with removing roster entries. I haven't figured it out from the source yet, but it seems like there's a small, but elusive, bug in how ECFConnection handles Smack's RosterPackets.

I currently have a workaround for this. I search for and remove invalid roster entries whenever I receive a roster update. Obviously this isn't ideal.

Thanks for the help!

Thanks for the help!

Hi Scott,

The model is only part of the problem. Our main effort went into developing the functional logic behind the system, which was really challenging. Also the Java platform is not complete enough to solve all of the equations: we even had to go as deep as the Link Layer, using ARP to solve some ambiguities.

We can't/couldn't do this in the short term (i.e. Galileo) because of API freeze, but we certainly could do it in ECF 4.0 (if there's enough interest and time, of course). Also, Markus has been/is the lead for the discovery work, so the final call is his.

But...API and code contributions...and new committers...can/would make this a much easier decision (as always).

Helping the community by contributing is always high on my to-do list. Unfortunately, some company policies prevent it. In cases where the use of the Eclipse platform is questioned, because of company politics, it's a luxury you simply cannot afford.

I understand.

Good news is that for my RFID-enabled Eclipse IDE project, I'm back on the ECF trail. If there is anything worth offering back in return, I won't hesitate. Does RFID makes sense in ECF?

to demonstrate advanced collaboration techniques, so maybe it does... how do you feel about that?

Also, something that might become a reality in the near future is work on a POSIX IPC library. I have proposed the use of POSIX IPC (NamedPipe, Semaphore, SharedMemory, ...) to further the adoption of Buckminster (big fan, here - see buckminster-dev). Someone called Clark Hobbie developed a very nice Java wrapper for POSIX IPC. It's early stages, but there is a real potential to turn this into something very powerful. The project feels orphaned a bit at the moment, and I must admit that I was thinking whether it could find a welcoming home in the ECF project in eventually...

Thanks,

Scott

I empathize with the effort here in creating a common abstraction for device/service discovery, but wouldn't it be great to prevent this same effort for future generations of discovery users? :) IMHO it sure would be better than living with the 'one discovery protocol to rule them all' approach that the various protocol implementers take...and that the software implementers have to live with).

@Scott: is there an impediment to make the device/service distinction in ECF model primitives?

The main impediment for us: Time to define and add to the existing discovery API (I'm assuming that it can/could be formulated as an addition).

We can't/couldn't do this in the short term (i.e. Galileo) because of API freeze, but we certainly could do it in ECF 4.0 (if there's enough interest and time, of course). Also, Markus has been/is the lead for the discovery work, so the final call is his.

But...API and code contributions...and new committers...can/would make this a much easier decision (as always).

Best regards,
 Dann