Tag Archives: client

feeds

Jean-Louis Seguineau: Unnecessary "interoperability" drafting

2011/09/25 – 00:45

After some time out of the communication realm, I will comment on the presentation of an Internet-Draft that defines how to enable basic interoperability between SIP/SIMPLE and XMPP.

It is funny how interoperability and federation between different communication media is always reduced to "mapping". This is once again exemplified by the draft proposal trying to explain how to achieve this hypothetical interoperability. From the architectural assumption, we already get the feeling this is too good to be true. Being amongst the very few people having implemented a federation between these two protocols, and probably the only one having designed a native SIMPLE connectivity on an XMPP server, I can tell you this is slightly more complex than the draft describe…

The draft goes to great length to describe how to convert between a SIP URI and an XMPP JID. This is an excellent and accurate work, and its undisputable merit lies in providing in one single document a thorough description of each address' syntax. But in real life, what are the chances for the addresses in these two communication spaces to require direct translation?. Not very high. Why would the syntactical similarity between a SIP URI and an XMPP JID provide a guarantee that the same address must be used? After all, we do not translate JIDs directly to email addresses, nor SIP URIs either. We do not translate AIM screen names to SIP URIs, nor to JIDs. In the real world, we perform a lookup of one communication space's address in the other... We use directories to achieve the "mapping", rarely direct translation. The only case where this would be used is when SIP/SIMPLE user agents connect directly to an XMPP server, which is somewhat uncommon.

Where the draft is not up to the task is when trying to map the long term presence subscriptions of XMPP with the short term subscription of SIP. It is all fine when there are no existing subscriptions form either side. In this case, translating an XMPP subscription into a SIP SUBSCRIBE would provide the desired effect. But only the first time. The next time, the permanent XMPP subscription will trigger a presence stanza, instead of a subscription stanza. Nothing in the draft addresses how to handle this difference. In SIP we have a well delimited publish-subscribe behaviour. In XMPP we have a variable context behavior: before and after subscription.

The draft indicates that the XMPP subscription could be terminated by the SIP subscription. But this is not realistic. From an XMPP user's stand point this would mean re-subscribing to the contact on every login. And further on, this would force the XMPP user to accept a SIP contact's subscription for every contact’s log in.

Working the other way round is easier, as it is always possible to translate a SIP SUBSCRIBE into an XMPP subscription. If no subscription exists for the SIP contact, the subscription stanza will be sent to the XMPP user's client if and only if the user is online. If the user is offline, the subscription will be stored by the XMPP server, awaiting the user's acceptance. So the gateway will have to deal with this case, which is not described in the draft. Similarly, the draft does not handle the case where the XMPP user refuses the SIP contact's subscription. In SIP, if a subscription is refused it translate into an error response. The gateway would have to be aware of the presence state of the XMPP user to take the right decision. This asynchronous handling does not easily "map" with the request/response nature of SIP. Following the proposed scenario, the gateway would have to maintain a copy of every user's presence. This is both inefficient and non scalable. And again not very realistic.

As said above, SIP presence is based on short lived publish-subscribe, initiated by the requesting user agent. This is the opposite of XMPP, where the server acts as a proxy for the client user agent. SIP relies on expiration to cancel subscriptions. XMPP sessions do not time out. SIP is connectionless, whereas XMPP relies on the client connection state to deduce the end of a client session. All these fundamental differences are not highlighted in the draft, and as a consequence the cases described are both superficial and incomplete.

In the end, I find no real value in issuing a document whose only real complete description is in highlighting the difference between XMPP and SIP address handles representations. It is also detrimental to reduce interoperability between the two protocols as a simple translation between message types. None of the real issues of application interoperability are addressed in this document which looses all its substance, and by consequence its necessity. Beyond having “the longest title in IETF history” I believe this draft would be better off retracted. This energy might have a better result applied to the Jingle specification…

Technorati Tags: , , , , , ,
Tags , , , , | Permalink | Comments Off
feeds

Mysql bashing

2011/09/19 – 00:43

Pouring soju

I wrote a couple of bash scripts to insert and update information into a mysql database.

  1. Imagetrack
  2. pyblosxom2wordpress

They are both disappointingly slow interfacing with the mysql client. Though with the help of imagetrack, I’ve managed to collate information of about 20000 images of mine on different machines in an hour. I hope to do some analysis with this information. Like figure out which images are corrupted or have had their EXIF mashed or their time wrong.

pyblosxom2wordpress is a script to insert old blog entries from my previous blogging system pybloxsom. This has been on my TODO for a long time.

Finally I got around to doing it. Most of the old blog entries are quite embarrassing. Oh well, they’re are all here now. One could use the script to continue writing their blog in a blosxom fashion and periodically run my script to insert the new entries.

Whilst examining the Wordpress MySQL DDL, I found it could do with some better restraints. Perhaps they kept it loose for other DBMSes.

Tags , , , , | Permalink | Comments Off
feeds

Support for STARTTLS and SASL in s2s Connections

2011/08/07 – 12:43

Why Server-to-server Encryption?

As shown in the following figure, messages transmitted to and from other Jabber servers can be intercepted in case client connections (c2s) or connections to other Jabber servers (s2s) are unencrypted. In this situation, it is fairly easy for a cracker or script-kiddie to intercept your users' conversations.

Tags , , , , | Permalink | Comments Off
about

Welcome to jaim.at!

2011/05/04 – 14:39

Welcome to JaIM.at’s public Jabber Instant Messaging (IM) service, you can interact with millions of other Jabber users worldwide!

Please register your Jabber ID with a jabber client of your choice to join the Jabber network, if you want a web client there’s jappix.jaim.at a full featured, web based jabber client available.

Jabber is an excellent and secure instant messaging protocol. You can choose your own server to use, similar to mail. A list of available clients for various platforms is available at xmpp.org.

The owners of JaIM.at are not responsible for the content of our users’ pages and input. JaIM.at provides no warranty that the service will be uninterrupted or error-free. We assume no liability, expressed or implied, for any downtime for any reason.

Enjoy! FRZ

 

Incoming search terms:

Tags , , , , , , , | Permalink | Comments Off
feeds

gitlive: display GitHub pushes in realtime on your website

2011/02/03 – 16:26
Transport protocol Most efficient protocol?

The client will attempt to connect using the WebSocket transport to ejabberd. WebSockets are a bidirectional protocol that solve one of the problems HTTP can't solve — by design. Many crutches have been built on HTTP to solve this problem. In the XMPP world it's BOSH. But it's not efficient on the server and on the client (think mobile applications).

WebSockets will solve all this. "Will solve" because even though we have implementations in the latest versions of Safari, Chrome, Firefox and Opera, it is still an IETF draft. Little progress has been done on the subject in the last year, and the latest iterations of the protocol are not implemented. For a good overview of the issues, Dave Cridland has you covered.

But still there is an installed base we can build on. So there, we have developped a native websocket server implementation for ejabberd. And for browsers not supporting websockets, we have Adobe Flash™.

Flash?

Yes, the irony isn't lost on us either. A nice project available on GitHub, web-socket-js, implements the WebSocket API on the client and the protocol towards the server. So if you have Flash and no native WebSocket support, the gitlive widget will load the Flash file. It's only 18Kb.

Back to BOSH

If all the previous techniques fail, the widget will attempt a BOSH connection. It's many times slower than websockets and consumes more resources on client and server. But it's very failsafe as it works everywhere vanilla HTTP works.

This combination of transport mechanisms make sure that gitlive notifications can be viewed with any browser, any time.

Front-end

The rest of the code is pretty much straightforward. The client code uses a combination of StropheJS and jQuery, and the commits are templated with mustache.js. Clients connect using anonymous authentication and subscribe to the project nodes.

It also uses the p1:rebind feature, a mechanism enabling fast rebinds to a previous connection.

You can actually customize the commits by overriding the CSS and mustache templates:

var GithubPush = {nodes:["cstar/erlang-oauth"],

location:"#commits",

css: "http://web.site/your.css",

template: "inline mustache template"};

This is default mustache template:

"
  • "

    + ""

    + "{{name}}

    " + "
    {{repository_name}}
    " + "

    {{title}}

    " + "{{time}}
    " + "
    {{message}}
    GitLive
    • "

    "

  • "

    • + ""

    + "{{name}}"

    + "

    {{repository_name}}
    "

    + "

    {{title}}

    "

    + "{{time}}"

    + "

    {{message}}
    GitLive"

    Note: that would be nice if you'd leave a link back to http://gitlive.com/ with your custom templates.

    The default CSS is available here.

    Back-end

    It is a very streamlined ejabberd 2.2. The only module activated is mod_pubsub. On the HTTP side, we have our custom websocket module, the http-bind module and the GitHub webhook.

    After each push, GitHub will POST on the webhook a JSON payload with all the meta-information about the the commits just pushed. The GitHub webhook will create the pubsub node if necessary. (That's why you need to Test Hook on the GitHub admin inteface). The JSON payload is converted to an Atom PubSub payload, and published on the node. ejabberd takes care of the rest, distributing the payloads to subscribers.

    Bugs

    There are still a couple of bugs that I hid under the carpet. But this time, and this time only, I am going to remove the carpet:

    BOSH connections are not reattached. The last item is not sent in that case. WebSocket connections need to resubscribe to the channels every time even after rebind, putting an unnecessary load on the storage backend.

    Both bugs will be corrected soon, and workarounds are deployed to silence these bugs in the meantime.

    Future plans

    Though we plan to keep this product simple, but we will federate the gitlive serverwith the XMPP community. You will be able to get GitHub push notifications in real time in your favorite XMPP client. Provided it can parse Atom payloads. A little birdie told me that OneTeam will in a not-so-distant future.

    This product is also the first of a series enabling websites to add realtime notifications, events, or ... Javascript.

    Tags , , , , , | Permalink | Comments Off
    feeds

    Chat clients and transports: Why do I see this over and over?

    2008/11/14 – 17:17

    I tend to see the same set of things done over and over again in clients as they go from “I only care about XMPP chatting” to “users keep asking us for better transport support”. Many clients look for bare JIDs in your roster and treat them in a special manner, which is fine except in some cases I have bare JIDs in my roster and the service it’s attached to is gone, so the client gets a little confused. Clients like Psi will dutifully look for jabber:iq:register and offer that as an option on services. Many of them you have to go disco browsing to find the transports available in the first place. Nothing wrong with any of that. Some clients may choose to go ahead and look for things marked jabber:iq:gateway and add them to some special list. That’s not really what this is about though.

    A number of clients will add in basically “hacks” for individual chat services. Psi has “service icon sets”, and if it’s a new service that isn’t in Psi’s list, it comes up with default icons. Spark has a bizarre mechanism in which it explicitly adds support for each individual transport via what I call little java “nuggets”. But a common theme I see here is individually handling each service. Some new service comes along, now all of the clients have to be updated if they want to have cool icons. Personally I think that’s crap. ;) I’m a big fan of dynamic lists of things. In other words a client shouldn’t have to -know- about any of the specific transports. It should be able to simply pull a list of services on the server in question, if it wants gateway ones look for jabber:iq:gateway, and — and here’s the missing part — be able to retrieve whatever it needs to provide a nice experience to the end user.

    So what all tends to be custom added? Generally it boils down to icons. Icons icons icons. Icons for presence, Icons for representing the transport, etc etc. I don’t think I’ve ever seen anything beyond icons that couldn’t be determined from disco queries. So why couldn’t service icons be provided by the service itself? I could see something along the lines of using pubsub where the transport publishes it’s icon sets, one for service icons (maybe a set of different standardized sizes) and one for presence representation icons. That way a client could just come in and go “gimme the icons I should use” and move on. I admit my knowledge of pubsub is -still- limited, but my understanding is that there are version numbers associated with the published data, and the client could cache what it got and simply check for “is there a newer set?”.

    The primary caveat here that I can think of is, that pulls the ‘control’ of the icons away from the client and into the transport, and there’s always a chance that the client doesn’t “like” the icons the transport is sharing. Of course, for the most part the clients are aiming to use icons similar to those of the service the transport is providing, so they kind of already have to deal with the possibility that for example AIM’s icon might not look great in their client. So the question is … would client authors use this or just end up scoffing at icons coming from the transports themselves?

    I suppose if the clients really felt like they needed to have different icons for some services, they could always override what they’re getting from the transport and do their own anyway. It just always feels like a hackjob to me to see things like “if this JID matches with aim.* then use the AIM set”. Especially those instances make me cringe because JIDs can be anything for those transports, where the transports -will- be providing a gateway identity that tells you flat out what service it is, assuming the transport authors bothered to follow spec. ;)

    Incoming search terms:

    Tags , , , , , , | Permalink | Comments Off
    feeds

    ProcessOne launches the first business-class instant messaging client for the iPhone

    2008/11/05 – 15:42

    PARIS, FRANCE – 5 November 2008 – ProcessOne, an instant messaging (IM) solutions provider with over 35 million registered users in the world, today announced the launch of OneTeam, which is the first business-class IM client for the Apple iPhone. Built on ProcessOne’s renowned open-source IM platform, it provides business users with secure and flexible access to IM services.

    OneTeam can be downloaded from the Apple App Store on iTunes, giving users access to mobile IM on the iPhone and iPod Touch devices. OneTeam enables users to reuse their existing IM accounts through server side gateways, meaning they can get in contact with existing contacts on AIM® / MobileMe®, ICQ ®, MSN ® / Windows, Yahoo! ® and GoogleTalk®.

    OneTeam is ideally suited for business users as it can be used in a corporate environment with a businesses’ own XMPP server. For the IT department this means they can much more effectively manage IM, ensuring security and compliance, while at the same time giving users the flexibility of using the public IM accounts they are familiar with.

    “The iPhone is fast emerging as the device of choice for many business users, many of whom will require instant messaging capability,” said Mickaël Rémond, CEO of ProcessOne. “Our OneTeam client allows businesses to have the best of both worlds when it comes to IM by allowing users to continue to use public IM clients, but also providing the capability for them to be brought under the control of the IT department so they can be managed and maintained effectively.”

    OneTeam enables users to communicate using the software on their iPhone when connected to WiFi, 3G and Edge networks, enabling them to stay connected wherever they are in the world.

    Key features of the of the OneTeam service include:

    No per-message charges – OneTeam uses a users’ existing data plan Enables users to access their Gmail® account directly Clean and streamlined workflow Compliance with the open XMPP standard OneTeam can be used in a corporate environment with a corporate XMPP server Users can chat with their contacts on other IM networks

    “We are committed to making OneTeam an instant messaging application that users will love using, so will be continuing to develop the software and introduce new features. We will be actively soliciting feedback from our users to ensure that they have the functionality they need to communicate via IM to friends, colleagues and business partners in the future,” concluded Mickaël Rémond.

    OneTeam is available at the Apple App Store on iTunes and costs €4.99 (£3.49) to download.

    References:

    OneTeam for iPhone home page OneTeam on Itunes Appstore About ProcessOne

    Founded in 1999, ProcessOne is a specialised creator of high performance instant messaging solutions. The company actively develops the instant messaging server ejabberd and offers a high level of commerical support throughout the world. ProcessOne is one of the principal providers of instant messaging solutions and real time communications services.

    ProcessOne’s solution has become the benchmark in the deployment of high performance instant messaging solutions. Solutions are for enterprises who want to deploy an internal instant messaging solution with or without interconnection with existing networks (MSN, Yahoo!, AOL). They are also for online communities that want to improve the services offered to its users. Known for its robustness under heavy loads, the solution is deployed with important clients around the world for building personalised services (Meetic, Portugal Telecom, SIPPhone, Nero) and today has over 35 million users.

    For further information please visit : http://www.process-one.net/

    Tags , , , , , | Permalink | Comments Off
    feeds

    AOL and XMPP: Probably the 803rd post about this you’ve read!

    2008/01/18 – 21:14

    You’ve probably at least seen:

    http://florianjensen.com/2008/01/17/aol-adopting-xmpp-aka-jabber/

    So I played with this a little yesterday .. very cool! I certainly hope that AOL does indeed go through with this and embrace XMPP! Based off my experience with OSCAR and XMPP, they -could- accomplish everything they’re currently doing with OSCAR with XMPP. Do they want to? Is this simply a gateway to their AIM and ICQ services? Who knows, but it’s good to see! I would imagine AOL has already seen how excited folk are about this, probably by their poor test server getting suddenly wailed on. I can only hope they won’t decide this is a bad idea. The thing is, people like to use AIM and ICQ. People like to use XMPP. Why do they have to be at odds? AOL’s take on how chatting should work could bring wonderful improvements to XMPP overall. I think Google’s joining the fray did a lot of good for XMPP in general in terms of XEPs that came about because of it and such. And people like me wouldn’t be spending so much time building transports or multi-protocol clients if we didn’t at some level like the services we were connecting to. For example, I don’t hate AIM. I simply like a lot of protocols and don’t want to run 8 different chat clients on my desktop. I also think the OSCAR protocol is interesting, as are the other protocols, so I wanted to learn more about them. Does that mean I’m out to make XMPP overtake AIM? Hell no. To be frank, it would be a happy day to me if the transports were no longer necessary, if people on AOL’s servers could chat with people on my own server and on jabber.org’s server and on lots of others without having to figure out the protocols. Does this mean no one would try to dissect the protocols anymore? Probably not. Part of the drive of that is learning and understanding. It doesn’t have to be about trying to circumvent.

    Imagine if AOL decided they really liked XMPP overall and ditched OSCAR though. That would hose old clients. But what if they released a new client that spoke XMPP while keeping their old servers going? Furthermore, what if that client could point at other servers than AOLs. Now AOL has a nice client or two out there for any XMPP clients to use. That’s kinda cool! There’s plenty of great XMPP servers out there at this point. The client choices in general are a little lacking. Spark, of which I’m in charge of nowadays, is pretty, it’s cross platform, but it’s a beast. Java is not necessarily great in terms of small memory footprint. Coccinella has a lot of cool features but it’s Tcl/Tk and I’ve never liked the “feel” of Tcl/Tk. Google Talk, there’s not a version for my OS, so what good does it do me. iChat… nothing personal Apple but I’ve never liked it. I can’t put my finger on why really. It’s also hard to explain why I don’t use Psi for everyday use. I love it for development. Nothing is better IMO. But for some reason it didn’t feel simple enough to be something I want to use as a regular client. Adium X and Pidgin? It’s the primary client I use but it lacks a lot of XMPP functionality (though it’s definitely improving on that front) All of these are good clients, and have good followings, but there’s still a lot of room for other ‘entries’ to come into the mix. Nothing seems to “do it” for everyone yet. Of course, who knows if that will ever happen. But seriously AOL, I’d love to see you throw your hat into the mix!

    Now what about MSN and Yahoo and others? Yahoo, I could see them possibly embracing XMPP. Hell they bought Zimbra and Zimbra’s suite has XMPP capabilities nowadays, so they have some bought expertise there. MSN on the other hand, they sell a product (LCS? OCS? whatever it is) that may be a good drive -not- to embrace XMPP. I don’t know much about OCS or LCS though.

    Overall though, this kind of reminds me of e-mail. Everyone can have their own implementations of email services and such, that doesn’t mean we can’t all speak the same language! AOL, I hope you take all this attention as a compliment! I think we’re all proud and pleased to see you express an interest in XMPP and maybe join the family!!!

    Incoming search terms:

    Tags , , , , , , | Permalink | Comments Off
    feeds

    Coccinella: 8 Years and More: The Roots of Coccinella

    2007/12/01 – 21:20
    Birthday balloons for Coccinella
    Credit: D. Bell, License: by-nc

    Exactly 8 years ago, on the 1st of December 1999, the first official release of an application called Whiteboard was released. In 2003, Whiteboard was renamed into Coccinella. Happy 8th birthday Coccinella!

    Read on for a more complete history of 'the beginning' and to read about Coccinella's birthday presents.

    The 'Before Coccinella' Era

    Somewhere in 1998, Jeremie Miller started working on Jabber, a project that gave birth to innovative instant messaging protocols which are used today in an increasing number of instant messaging applications, including Coccinella. In November of the same year, another well-known instant messaging project named Gaim (now Pidgin) was started.

    In January 1999, the Jabber project was officially announced.

    The Birth of Coccinella's Roots

    Throughout 1999, the Tcl community worked on a Jabber client called zABBER and a Jabber client library called JabberLib. We do not exactly know when these projects were started, though we found a development snapshot of zABBER which was released on the 12th of April. Note that the original zABBER website is still online (!!) and screenshots and snapshots of this prehistoric software can still be downloaded. In September 1999, the tcl.jabber.org site was created. This was the home of the Jabber Tcl/Tk Team.

    For those who are interested, I tested the latest zABBER release and it still works to some extend (connecting, presence, receiving messages, replying to received messages) with some of today's Jabber servers...8 years of compatibility of the base Jabber protocols which were still in heavy development in 1999!

    The Birth of Coccinella

    As already said in the introduction, the first official release of Coccinella was Whiteboard-0.90, released on the 1st of December 1999. We don't know when Mats actually started working on Whiteboard, but maybe he can add a comment to this post with a guess and/or additional interesting details he still remembers about 1999... B-)

    You may think Coccinella always has had support for the Jabber/XMPP protocols but this is not true. On the 27th of January 2002 (coincidence?), Whiteboard-0.93 was released. This was the first release 'adapting to the jabber XML IM server system'. The peer-to-peer "Whiteboard protocol" was only removed earlier this year, in Coccinella 0.96.0. Also, it would be cool if Coccinella could adapt to a good whiteboarding XEP...which first should be made of course. See also Mat's related memo on synchronisation. /me pokes the XSF. ;-)

    		 Balloons for Coccinella
    Credit: K. Tate, License: by-nc-sa

    Cheating

    Implementing Jabber support was not as tough as it could have been thanks to the work done by the Jabber Tcl/Tk Team in 1999 and beyond. Mats 'simply' could recycle the JabberLib client library made by this project (Mats' fork of JabberLib). Five months later, on the 3rd of July, the Tkabber project repeated the same trick by forking JabberLib for a second time. So, today there are 2 separate forks of the original JabberLib. This also means that these are probably (correct me if I'm wrong) only 2 active Jabber-only clients which have such mature Jabber roots.

    Besides that, there are at least 2 projects using Mats' JabberLib fork. However, which projects these are and more details about these projects will be the topic of a further blog post as this one is already getting too long :-)

    Birthday Presents

    We have 2 presents for Coccinella's birthday. First, there is the updated website design including Néstor Díaz's new logo design (do you like it?). Secondly, there is a secret present which will be revealed tomorrow. So, stay tuned!

    Tags , , , , | Permalink | Comments Off
    feeds

    Hal Rottenberg: Trying out NetCmdlets

    2007/11/15 – 17:24
    Jabber

    /n software has a PowerShell snapin (a set of cmdlets) called NetCmdlets that I’ve been meaning to check out for some time but never got around to it.  Well, today I needed to do some FTP stuff in PowerShell and I didn’t feel like messing with Sapien’s free FTP COM object as it seemed a bit clunky.  I’ve had this NetCmdlets license offer sitting on my desk for a few months so I went ahead and took the plunge.  :)

    I don’t have much to say about them yet except to say it looks really comprehensive.  They charge $99, but you sysadmins out there might want to justify purchasing it if you are getting into using PowerShell to manage your systems.  One really cool thing about these is that it’s all about manipulating many standards-based protocols.  That means cross-platform support.  Oh, and it does XMPP too, niiiice.  (Cross-posting to Planet Jabber… :) )

    Here’s a blurb from their website and the readme:

    The /n software NetCmdlets extend the features of Microsoft Windows PowerShell with a broad range of network management and messaging capabilities. The current release contains more than 30 Cmdlets providing access to network and host protocols such as SNMP, LDAP, DNS, Syslog, HTTP, WebDav, FTP, SMTP, POP, IMAP, Rexec/RShell, Telnet, and more.

    Networking Tools for IT Professionals

    The current package contains the following Cmdlets:

    • [get/set]-snmp : Command-line SNMP Management capabilities.  Manage network devices directly from PowerShell.
    • [get/send]-trap : Monitor and send SNMP Traps.
    • [invoke]-ssh : Secure Shell enabled remote access Cmdlet
    • [invoke]-rexec : Remote execution via Rexec
    • [invoke]-rshell : Remote execution via Rshell
    • [get/set]-ftp : FTP file transfer capabilities with advanced proxy and firewall support.
    • [get/set]-ldap : Access Active Directory or OpenLDAP servers through LDAP directory access
    • [get/send]-udp : Send and receive UDP datagrams. Send Wake On LAN requests.
    • [get/send]-nntp : Command-line newsgroup browsing.  Monitor newsgroup postings and post messages to newgroup servers directly from PowerShell.
    • [get/send]-syslog : Syslog server and client for LAN event monitoring and reporting.
    • [get/set]-tftp : TFTP file transfer Cmdlet.
    • [convert]-data : Encoding and decoding utilities including Base64, SHA1, MD5, BinHex, and more.
    • [read/write]-zip : Compressions and decompression Cmdlet supporting Zip, Tar, GZip, and Jar.
    • [get/set]-webdav : WebDav client Cmdlet.
    • [get]-http : Web client Cmdlet with advanced proxy and firewall capabilities.
    • [get]-packet : Monitor network interface traffic.
    • [get]-time : Access network time servers and synchronize machine clocks.
    • [get]-rss : RSS client Cmdlet enables retrieval of RSS Syndicated content.
    • [get]-whois : Domain name Whois lookup.
    • [send]-im : Send Jabber(XMPP) Instant messages.
    • [send]-sms : Send SMS(SMPP) instant messages
    • [send]-ping : Network ping capability to monitor device availability.
    • [get]-trace : Traceroute Cmdlet for determining the path of network packets between hosts.
    • [get/set]-ras : Cmdlets for RAS connectivity.
    • [send]-email : Send HTML emails with file attachments, supports SSL.
    • [get/set]-imap : Retrieve and manage messages, mailboxes and users in an IMAP server.
    • [get]-pop : Retrieve and manage messages in a POP server.

    Happy PowerShelling!  (And don’t forget to check out the podcast I co-host, PowerScripting Podcast.)

    Share This

    Tags , , , , | Permalink | Comments Off
    feeds

    Adam Nemeth: Meebo invented everything for us in 2007(?!)

    2007/11/11 – 01:34


    If there would exists a "Jabber Innovation Award 2007" I would definitely give it to Silicon Valley-based Meebo. Their platform, built on top of libgaim and jabber, offers the following things currently:



    Pretty awesome list, isn't it?

    I recommend to try it for yourself, as I said above, registering a meebo user means effectively having a jabber address - using other systems happen through gaim.

    While we're trying to push out new XEPs, they realized two things:

    • Web is the platform you should build on, because it's independent from nearly everything, yet quite popular

    • If you have a disadvantage (being a browser-based client it isn't fashionable for geeks) you better start to innovate.

    • Even if you're based on jabber, you should make sure protocol does not matter: it's the client which does the user experience



    If we could only ask them, how they achieved this, and how we could make this a common knowledge of humanity and ourselves!

    (The author still dreams of having an open meebo platform-like solution for desktop clients too through standardizing and WebKit/Gecko/CHtmlView)
    Tags , , , , | Permalink | Comments Off
    feeds

    Coccinella: Multiple Accounts Support

    2007/11/10 – 18:38

    Regularly, people like you ask us why Coccinella does not support multiple accounts. Or they ask if support could be added. We always have to disappoint them. Coccinella does not support multiple accounts and it is very unlikely Coccinella will ever support multiple accounts.

    In order of importance, these are the reasons why:

    1. Coccinella is targeted at stupid people for whom this feature does not add any value. We define stupid people as those who do not yet use XMPP or those who never used instant messaging before.

      We also believe that support for multiple accounts destroys value for these stupid users. Did you have ever seen any official proprietary network instant messaging client with this feature? Did you have ever seen an instant messaging client with this feature without related usability issues?

      Stupid people want to start with Coccinella without using their brains. A failure in providing a brain-less interface will wipe a new XMPP user away even before he could get started.

    2. We do not target Psi users, Gajim users, Pidgin users, Kopete users, and so forth. The minority in the whole instant messaging user population that really needs support for multiple accounts already has plenty of client choice. Coccinella is not yet another look-a-like; Coccinella is leading the way instead of following.

    3. If people really need support for multiple accounts they can use a server-side XMPP-to-XMPP transport.(*)

    4. Adding and maintaining support for multiple accounts is a challenging task requiring many resources that can better be spend on more sexy features like video conferencing. Or in Mats words:

      "If I may take the moderators middle standpoint there is one fact that makes the question simple. Although the jabberlib is built in an OO manner, the rest of the code that interfaces jabberlib isn't structured in a similar way. It is therefore a huge task to restructure essentially all code to keep track of which jabberlib instance to use for each task. Essentially all code, or at least a lot of code, need an extra jlibname argument, and I can tell you it is a lot of work."



    (*)After recently trying both J2J and the IM Gateway plugin (for Openfire only), I have to agree that the current state of both solutions is not ideal. The least worse of both is J2J which does not shows your contacts of the other account in your list. The Openfire transport is quite useless for the simple reason that it is limited to only 1 predefined server. So, if you have an account on the jabber.se server while the administrator of your server configured the Openfire plugin to use jabber.org, the transport will not work for you. Besides that, the Openfire plugin only works with Openfire. Hopefully, all these issues will disappear in the future. Though mostly focused on proprietary networks, our wishlist for transports lists some points also valid for XMPP transports.

    Tags , , , , | Permalink | Comments Off
    feeds

    Mark Derricutt: Messenger 9, GTalk integration, Messenger API, new client for Mac OS X – news unveiled at Georgia Tech presentation (whew) – LiveSide – News blog

    2007/11/06 – 04:32

    Is Microsoft finally recognizing the power of the XMPP/Jabber protocol for IM? It doesn't quite sound like it, but would be good to see them just adopt XMPP natively (even if they did so in a Microsoft styled walled garden network).

    Internal builds are already at WLM 9 and includes many of the API components. They have a team working on multi-person audio/video chat for WLM that may or may not be in 9, but should be in by 10. They are also trying to work out a way for WLM users to chat with AIM/GTalk/ICQ users like the way Yahoo! works now, and they have an internal version that works with GTalk already (but very basic). MS will no longer update the MSN Messenger for Mac, but they are going to release a brand new client for Mac OS X that is according to him "Really, really cool and awesome" but he would not provide anymore details due to his NDA. [From Messenger 9, GTalk integration, Messenger API, new client for Mac OS X - news unveiled at Georgia Tech presentation (whew) - LiveSide - News blog]

    Leave Comment

    Related Entries:

    Tags , , , , | Permalink | Comments Off
    feeds

    Peter Saint-Andre: Ψ

    2007/10/22 – 23:34

    For the past six months or so my preferred IM client has been Psi (that’s pronounced “psee” if you honor the ancient Greeks). For a long time I resisted using Psi because I didn’t like its ICQ-ish appearance in the old days, but in its more recent versions (such as the just-released 0.11) Psi has several significant virtues as far as I’m concerned:

    • It handles my huge buddy list [tm], which as of today has 1619 people in it. (Special thanks to Remko for the optimizations!)
    • It enables me to search for people in my roster — when you have 1600+ people in your roster, this is critical.
    • It performs all the advanced multi-user chat use cases such as room moderation, which I need because I’m a server admin at jabber.org.

    So here’s to Psi 0.11 — I’m looking forward to 0.12 (tabbed groupchats!) already. :)

    Tags , , , , | Permalink | Comments Off
    feeds

    Remko Tronçon: Introducing Greem

    2007/10/14 – 16:16

    After a short hiatus, I finally resumed work on my new Jabber/XMPP client project, which I christened `Greem’. The main goal of the project is to create a mobile Jabber/XMPP client for the Qtopia platform. The nice thing about Qtopia is that its target audience keeps on expanding: besides running on the GreenPhone (of which Trolltech was kind enough to provide me with one), Qtopia has recently been ported to the Neo 1973 (OpenMoko), and even Windows CE and Windows Mobile. In this post, I briefly describe what the expectations and the goals are for Greem, and how Psi fits into the picture.

    Tags , , , , | Permalink | Comments Off
    feeds

    Coccinella: Entity Capabilities

    2007/10/03 – 09:12

    Entity Capabilities is a method to reduce traffic by adding a compressed variant of disco info results in presence elements. Recently the XEP-0115 got an update which unfortunately breaks backwards compatibility.

    With version 1.3, clients used a presence stanza of the form

    where it was possible to use the node attribute to identify a particular client, your own, for instance.

    However, with version 1.4 a presence element

    where the actual client version has been appended to the node attribute, and the ver attribute has got a new meaning as a hashed version of the entities disco info result, see the XEP. The new protocol is much more practical than the old one, but a side effect is that already released client versions wont understand the new node attribute since the additional "#0.9.1" node part confuses them. It therefore takes a few release cycles before it is possible to make a complete switch to Entity Capabilities version 1.4.

    Tags , , , , | Permalink | Comments Off
    feeds

    Artur Hefczyc: Tigase service and MSN transport from client side.

    2007/09/27 – 01:25

    MSN transport is a separate module which allows you to connect to your MSN account and contact with other people from MSN network from your Jabber client. We use PyMSN-t application as a MSN transport which is a separate project from Tigase server. Both applications integrate very well and detailed configuration instruction is available in this guide.

    At the moment MSN transport installed on tigase.org server is available for local users only so you need to register an account on Tigase Website before you can start using it.

    You also need an account on Hotmail server and a Jabber/XMPP client of your choice:

    There are many other clients available...

    Here are instructions how to use the MSN transport on tigase.org in different Jabber/XMPP clients.

    read more

    Tags , , , , | Permalink | Comments Off
    feeds

    Artur Hefczyc: Website improvements

    2007/09/22 – 22:12

    Both Jabber/XMPP Web clients (Jeti and JWChat) are installed and are available on Tigase Website.

    They both offer auto-login function for site guests that is visitors who don't have an account on Tigase Website. Simply click on a link and you will be automatically logged in as a guest. Guest account has an initial roster with myself in buddy list so you can easily chat with me if I am online or leave me a message if I am away.

    Tigase Website share accounts with Jabber/XMPP service on tigase.org server. If you have an account on the Website and you are logged in then clicking on Web client link will open application with your user name and all you need to do is enter your password.

    Jeti uses a regular c2s protocol and you can also use it to login onto your account on any server.

    JWChat uses a bosh protocol and you can only login to tigase.org server with this client. Bosh protocol has been greatly improved recently and it will be included in new version of Tigase server.

    There is also a persistent multiuser chat room publicly available on the server: talks@muc.tigase.org. Please connect if you want to talk about Tigase project in general.

    read more

    Tags , , , , | Permalink | Comments Off

    Next Page »

    Next Page »