Tlen transport and Add Contact dialog

[sander]

The Tlen service is not showed as an option in the Chat systems dropdown list of the Add Contact dialog.

Test server: jabberpl.org

[Mats (matsben)]

I have added a few fixes here and there but is unable to test it since jabberpl.org refuses inline registration. Please verify.

[sander (s-devrieze)]

Reopened as it is not fixed yet. Remeber you can discover jabberpl.org (same for chrome.pl). I also tested by creating an account on jabbim.pl (this works!) and it is not fixed! Note that it takes ages before the services list is loaded...I think Coccinella is blocked for 30 secs on my Mac!!!

[Mats (matsben)]

I had one fix missing but the main issue is that it returns as
"gateway/x-tlen" which is wrong, see
http://www.xmpp.org/registrar/disco-categories.html#gateway . Some
gadu-gadu components also prepend an "x-". They have also
misunderstood the gateway prompt and returns them as:

() 3 % parray Gateway::gateway
Gateway::gateway(desc,gadu-gadu) = Proszę podać numerek GaduGadu
użytkownika z którym chcesz się skontaktować.
Gateway::gateway(desc,icq) = Ange användarens ICQ-användarid (uin).
Gateway::gateway(desc,msn) = Enter the user's MSN account.
Gateway::gateway(desc,x-tlen) = Wprowadz login Tlen osoby z ktora
chcesz sie skontaktować.
Gateway::gateway(prompt,gadu-gadu) = Numerek GG
Gateway::gateway(prompt,x-tlen) = Login Tlen

I have discoed both jabberpl.org and jabbim.pl from my mac and it
works very smooth.

On 1/17/08, sander <email address hidden> wrote:
> Reopened as it is not fixed yet. Remeber you can discover jabberpl.org
> (same for chrome.pl). I also tested by creating an account on jabbim.pl
> (this works!) and it is not fixed! Note that it takes ages before the
> services list is loaded...I think Coccinella is blocked for 30 secs on
> my Mac!!!
>
> ** Changed in: coccinella
> Status: Fix Committed => New
>
> --
> Tlen transport and Add Contact dialog
> https://bugs.launchpad.net/bugs/181572
> You received this bug notification because you are a bug assignee.
>

[sander (s-devrieze)]

Can you maybe document on a page in the development section of the website all protocol incompatibilities you found? (or just blog about it)

PS: there is no icon for Tlen...

Anyway, now I get this error when logging in to my jabbim.pl account:

can't read "icons(status/ask)": no such element in array
can't read "icons(status/ask)": no such element in array
    while executing
"return $icons(status/$suborig)"
    (procedure "::Rosticons::Get" line 82)
    invoked from within
"::Rosticons::Get $itype/$isub"
    (procedure "::Roster::GetPresenceIcon" line 42)
    invoked from within
"::Roster::GetPresenceIcon $jid $presence -subscription none -resource {} -type unavailable"
    ("eval" body line 1)
    invoked from within
"eval {::Roster::GetPresenceIcon $jid $presence} $args"
    (procedure "GetPresenceIcon" line 2)
    invoked from within
"GetPresenceIcon $jid $presence -subscription none -resource {} -type unavailable"
    ("eval" body line 1)
    invoked from within
"eval {GetPresenceIcon $jid $presence} $args"
    (procedure "::RosterPlain::CreateItem" line 13)
    invoked from within
"$plugin($name,createItem) $jid $presence -subscription none -resource {} -type unavailable"
    ("eval" body line 1)
    invoked from within
"eval {$plugin($name,createItem) $jid $presence} $args"
    (procedure "::RosterTree::StyleCreateItem" line 5)
    invoked from within
"::RosterTree::StyleCreateItem $rjid "unavailable" -subscription none -resource {} -type unavailable"
    ("eval" body line 1)
    invoked from within
"eval {
  ::RosterTree::StyleCreateItem $rjid "unavailable"
     } $args [array get presA]"
    (procedure "SetItem" line 43)
    invoked from within
"SetItem $jid -subscription none"
    ("eval" body line 1)
    invoked from within
"eval {SetItem $jid} $args"
    ("set" arm line 2)
    invoked from within
"switch -- $what {
 remove {

     # Must remove all resources, and jid2 if no resources.
         set resL [$jlib roster getresources $jid]
     ..."
    (procedure "::Roster::PushProc" line 13)
    invoked from within
"::Roster::PushProc ::jlib::jlib1 set sms.jabbim.pl -subscription none"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 $options(cmd) [list $jlibname set $jid] $args"
    (procedure "setitem" line 34)
    invoked from within
"setitem $jlibname $jid -subscription none"
    ("eval" body line 1)
    invoked from within
"eval {setitem $jlibname $jid} $opts"
    (procedure "handle_roster" line 38)
    invoked from within
"handle_roster $jlibname $queryE"
    (procedure "::jlib::roster::send_get_cb" line 5)
    invoked from within
"::jlib::roster::send_get_cb ::jlib::jlib1 {} result {query {xmlns jabber:iq:roster} 0 {} {{item {subscription to jid sms.netlab.cz/registered} 1 {} {}..."
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 $iqcmd($id) [list result $subiq]"
    ("result" arm line 11)
    invoked from within
"switch -- $type {
 result {

     # Protect us from our own 'set' calls when we are awaiting
     # 'result' or 'error'.
     set setus 0
     i..."
    (procedure "iq_handler" line 56)
    invoked from within
"iq_handler $jlibname $xmldata"
    ("iq" arm line 2)
    invoke...

[sander (s-devrieze)]

Seems the Gajim project also saw the bug in the Tlen transport: http://trac.gajim.org/ticket/2756

[Mats (matsben)]

"
Can you maybe document on a page in the development section of the
website all protocol incompatibilities you found? (or just blog about
it)
"

Too small issue to speak about.

On 1/18/08, sander <email address hidden> wrote:
> Seems the Gajim project also saw the bug in the Tlen transport:
> http://trac.gajim.org/ticket/2756
>
> --
> Tlen transport and Add Contact dialog
> https://bugs.launchpad.net/bugs/181572
> You received this bug notification because you are a bug assignee.
>

[Mats (matsben)]

The problem this time was also wrong disco-info, see http://www.xmpp.org/registrar/disco-categories.html. Iget:

<iq from='sms.jabbim.pl' <email address hidden>/Coccinella@Mats-Bengtssons-dator' id='1022' type='result'>
    <query xmlns='http://jabber.org/protocol/disco#info'>
        <identity category='service' name='Poland SMS transport' type='sms'/>
        <feature var='vcard-temp'/><feature var='jabber:iq:version'/>
 <feature var='jabber:iq:gateway'/><feature var='jabber:iq:agents'/><feature var='vcard-temp'/>
 <feature var='http://jabber.org/protocol/disco#info'/><feature var='http://jabber.org/protocol/disco#items'/>
    </query>
</iq>

and service/sms isn't a registered disco identity. My fallbacks for getting icons failed and I have now added more traps that will work in more situations. However, in this case there is just no category='service' so I return an empty image. Have no idea what "service" is supposed to mean and it is better not to assume anything.

In situations like this one it can help if you provide some more debug info like this: consider the top proc of the stack trace ("::Rosticons::Get") and add some puts statements, at least for the arguments since I don't always get them in the stack trace. And perhaps a few other puts so I can see what is happening. 90% of my time is spent trying to figure out what has happened and just a small part actually fixing it.

[sander (s-devrieze)]

2008/1/19, Mats <email address hidden>:
> "
> Can you maybe document on a page in the development section of the
> website all protocol incompatibilities you found? (or just blog about
> it)
> "
>
> Too small issue to speak about.

Wrong attitude! Then nobody will report it :-) My suggestion: start a
page where you collect all incompatibilities you find in different
software (Google Talk, Tlen transport, etc). When that page is big
enough you can blog about your collection of bugs :-)

The blog entry can start like this "Coccinella's friends are
everywhere. You can find these little animals called bugs not only in
Coccinella, but also in third party software. You can <a href="">view
my collection of bugs</a> in Google Talk, Tlen transport,...."

--
Mvg, Sander Devrieze.

[Mats (matsben)]

I could agree to add things like that on a page and when there is a
list of issues someone (you) could blog about it.

Two recent ones:
<identity category='gateway' type='x-tlen'/> instead of <identity
category='gateway' type='tlen'/>
<identity category='service' name='Poland SMS transport' type='sms'/>
instead of (?) <identity category='gateway' name='Poland SMS
transport' type='sms'/>

And now I remember the error in the setup of the gateway protocol I
reported recently. This was also a Polish server (same?).

Then there is the maintenance issue when things have been fixed...

On 1/19/08, sander <email address hidden> wrote:
> 2008/1/19, Mats <email address hidden>:
> > "
> > Can you maybe document on a page in the development section of the
> > website all protocol incompatibilities you found? (or just blog about
> > it)
> > "
> >
> > Too small issue to speak about.
>
> Wrong attitude! Then nobody will report it :-) My suggestion: start a
> page where you collect all incompatibilities you find in different
> software (Google Talk, Tlen transport, etc). When that page is big
> enough you can blog about your collection of bugs :-)
>
> The blog entry can start like this "Coccinella's friends are
> everywhere. You can find these little animals called bugs not only in
> Coccinella, but also in third party software. You can <a href="">view
> my collection of bugs</a> in Google Talk, Tlen transport,...."
>
> --
> Mvg, Sander Devrieze.
>
> --
> Tlen transport and Add Contact dialog
> https://bugs.launchpad.net/bugs/181572
> You received this bug notification because you are a bug assignee.
>

[sander (s-devrieze)]

> The problem this time was also wrong disco-info, see
> http://www.xmpp.org/registrar/disco-categories.html. Iget:
>
> <iq from='sms.jabbim.pl' <email address hidden>/Coccinella@Mats-Bengtssons-dator' id='1022' type='result'>
> <query xmlns='http://jabber.org/protocol/disco#info'>
> <identity category='service' name='Poland SMS transport' type='sms'/>
> <feature var='vcard-temp'/><feature var='jabber:iq:version'/>
> <feature var='jabber:iq:gateway'/><feature var='jabber:iq:agents'/><feature var='vcard-temp'/>
> <feature var='http://jabber.org/protocol/disco#info'/><feature var='http://jabber.org/protocol/disco#items'/>
> </query>
> </iq>
>
> and service/sms isn't a registered disco identity. My fallbacks for
> getting icons failed and I have now added more traps that will work in
> more situations. However, in this case there is just no
> category='service' so I return an empty image. Have no idea what
> "service" is supposed to mean and it is better not to assume anything.

So, another bug?

> In situations like this one it can help if you provide some more debug
> info like this: consider the top proc of the stack trace
> ("::Rosticons::Get") and add some puts statements, at least for the
> arguments since I don't always get them in the stack trace. And perhaps
> a few other puts so I can see what is happening. 90% of my time is spent
> trying to figure out what has happened and just a small part actually
> fixing it.

...looks like Swedish to me...can you also translate it in English for me? :-)

[Mats (matsben)]

On 1/19/08, sander <email address hidden> wrote:
> >
> > and service/sms isn't a registered disco identity. My fallbacks for
> > getting icons failed and I have now added more traps that will work in
> > more situations. However, in this case there is just no
> > category='service' so I return an empty image. Have no idea what
> > "service" is supposed to mean and it is better not to assume anything.
>
> So, another bug?

It can as simple as a configuration error in an xml file that was made
by the admin.
In any case we must be fault tolerant which I belive we are now, at least here.

>
> > In situations like this one it can help if you provide some more debug
> > info like this: consider the top proc of the stack trace
> > ("::Rosticons::Get") and add some puts statements, at least for the
> > arguments since I don't always get them in the stack trace. And perhaps
> > a few other puts so I can see what is happening. 90% of my time is spent
> > trying to figure out what has happened and just a small part actually
> > fixing it.
>
> ...looks like Swedish to me...can you also translate it in English for
> me? :-)
>

I can start talking machine assembly code language if you prefer that...
(Kidding, I don't know assembly language.)

[sander (s-devrieze)]

2008/1/20, Mats <email address hidden>:
> On 1/19/08, sander <email address hidden> wrote:
> > >
> > > and service/sms isn't a registered disco identity. My fallbacks for
> > > getting icons failed and I have now added more traps that will work in
> > > more situations. However, in this case there is just no
> > > category='service' so I return an empty image. Have no idea what
> > > "service" is supposed to mean and it is better not to assume anything.
> >
> > So, another bug?
>
> It can as simple as a configuration error in an xml file that was made
> by the admin.
> In any case we must be fault tolerant which I belive we are now, at least here

I don't agree with that. This is the mantra from WWW community and it
*sucks*. It's the main reason why you cannot make a good browser or
website by only looking at the available open standard specifications.
All browsers and all websites have exceptions and this make it
extremely hard for newcomers to enter the business as they all should
learn the exceptions by trial and error. Not only this is a huge task
needing more resources, but also it will make the code more ugly (also
the HTML source of a website). Also, when you add support for these
exceptions, the related projects and people will feel no need to fix
their bugs. That's why I *strongly* suggest against being fair to such
bugs. My advice:
1) Be strict in following the specs and give a high priority to fixing
your own bugs in this regard.
2) Make sure Coccinella does not crash due to another service or
software being wrong
3) Do not adopt to these exceptions, instead file a bug report
yourself or give me the required information and I'll forward the bug
to the right people.
4) If users complain something is not working because of such a bug in
another service, tell them it's a problem in the other service *and*
forward their complaint to the relevant project.

> >
> > > In situations like this one it can help if you provide some more debug
> > > info like this: consider the top proc of the stack trace
> > > ("::Rosticons::Get") and add some puts statements, at least for the
> > > arguments since I don't always get them in the stack trace. And perhaps
> > > a few other puts so I can see what is happening. 90% of my time is spent
> > > trying to figure out what has happened and just a small part actually
> > > fixing it.
> >
> > ...looks like Swedish to me...can you also translate it in English for
> > me? :-)
> >
>
> I can start talking machine assembly code language if you prefer that...
> (Kidding, I don't know assembly language.)

The issue is I'm too stupid to understand things like "consider the
top proc of the stack trace"...

--
Mvg, Sander Devrieze.

[Mats (matsben)]

On 1/20/08, sander <email address hidden> wrote:
> 2008/1/20, Mats <email address hidden>:
> > On 1/19/08, sander <email address hidden> wrote:
> > > >
> > > > and service/sms isn't a registered disco identity. My fallbacks for
> > > > getting icons failed and I have now added more traps that will work in
> > > > more situations. However, in this case there is just no
> > > > category='service' so I return an empty image. Have no idea what
> > > > "service" is supposed to mean and it is better not to assume anything.
> > >
> > > So, another bug?
> >
> > It can as simple as a configuration error in an xml file that was made
> > by the admin.
> > In any case we must be fault tolerant which I belive we are now, at least
> here
>
> I don't agree with that. This is the mantra from WWW community and it
> *sucks*. It's the main reason why you cannot make a good browser or
> website by only looking at the available open standard specifications.
> All browsers and all websites have exceptions and this make it
> extremely hard for newcomers to enter the business as they all should
> learn the exceptions by trial and error. Not only this is a huge task
> needing more resources, but also it will make the code more ugly (also
> the HTML source of a website). Also, when you add support for these
> exceptions, the related projects and people will feel no need to fix
> their bugs. That's why I *strongly* suggest against being fair to such
> bugs. My advice:
> 1) Be strict in following the specs and give a high priority to fixing
> your own bugs in this regard.

This is also my mantra.

> 2) Make sure Coccinella does not crash due to another service or
> software being wrong

This is what I meant by being fault tolernat. In this specific case
with service/sms
there wont be an icon and I don't try to map category/type into something else.

> 3) Do not adopt to these exceptions, instead file a bug report
> yourself or give me the required information and I'll forward the bug
> to the right people.

I don't adopt such changes, just makes sure we don't crash...

> 4) If users complain something is not working because of such a bug in
> another service, tell them it's a problem in the other service *and*
> forward their complaint to the relevant project.
>

Agree.
Seems we don't have any disagreement here at all :-)

> > >
> > > > In situations like this one it can help if you provide some more debug
> > > > info like this: consider the top proc of the stack trace
> > > > ("::Rosticons::Get") and add some puts statements, at least for the
> > > > arguments since I don't always get them in the stack trace. And
> perhaps
> > > > a few other puts so I can see what is happening. 90% of my time is
> spent
> > > > trying to figure out what has happened and just a small part actually
> > > > fixing it.
> > >
> > > ...looks like Swedish to me...can you also translate it in English for
> > > me? :-)
> > >
> >
> > I can start talking machine assembly code language if you prefer that...
> > (Kidding, I don't know assembly language.)
>
> The issue is I'm too stupid to understand things like "consider the
> top proc of the stack trace"...
>

Let me explain: when there is an err...

[sander (s-devrieze)]

I just added this bug to http://coccinella.im/third-party-issues (and I created a patch to fix the bug in the Tlen transport).

[Mats (matsben)]

This extra "x-" seen in many MIME types I consider as a design flaw. Not
sure why they added it. Probably it was a compromise with some commercial
vendor that created this mess (my guess).

[Lukáš 'Spike' Polívka (lukas-polivka)]

http://jtransports.xiaoka.com/changeset/85/jtlentrans/src/jabber/disco.c

JTlenTransport now correctly identifies itself as gateway/tlen.

tlen.jabbim.pl is running this version now

[Lukáš 'Spike' Polívka (lukas-polivka)]

Ticket for Polish SMS gateway (sms.jabbim.pl): http://jtransports.xiaoka.com/ticket/2 (I hope somebody reads it.)

Is there any problem with gg.jabbim.pl?

All these gateways should reside at http://jtransports.xiaoka.com/.

[Lukáš 'Spike' Polívka (lukas-polivka)]

smoku has fixed the problem with Polish SMS transports, now only service administrators have to roll out the update.

[Pascal De Vuyst (pascal-devuyst)]

Coccinella has no Ubuntu package, closing Ubuntu task.
If you want to request a new package for Ubuntu follow the steps described here: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages.