netzooid

While I love the concept of OpenID, I refuse to use it as it requires me to enter a URL for my login. This is the most inane thing to do from a human interface point of view.

As I was daydreaming about software last week, and in particular how to get around this, I started wondering “what if a Jabber extension was created for OpenID?”

Think about this:

• User enters email into web site to log in
• System sends jabber message to user (where their email is their jabber id) asking if they want allow the login.
• User responds yes/no.
• System grants/denies access based on the response.

Now consider the modified version.  The user opens their web browser. They tell the web browser to log into the jabber server and listen for messages on a specific jabber resource. Now all the user needs to do is enter there email for any OpenID site. (Maybe there is a way to get around the email entry too?)

One could also imagine a scenario which used SMS or other IM protocols. URLs definitely do not have to be the only identifier available to OpenID users.

There’s probably a whole host of issues with this, and I’m much too lazy right now to go research if its feasible via an OID extension, but I thought I’d throw it out there.

Ross finally got a blog. Ross: You’re only a few years late, but glad to see it!

Tatu on “So How Did It All Start?”:

As an author of a highly publicized software package, one often has to answer questions like above. That — in addition to the fame, money and chicks — is one of fringe benefits of being an uber-geek programmer doG.

But, ask you: how does that relate to me? Sadly, not in any way, shape or form. But I just thought I’ll start with such a claim to grab your attention.

The joys of being an open source developer! Read on for an amusing tail of how open source projects start.

Now that Galaxy is announced, I can unleash my fury of blogging again. Or, as we all know will probably happen, I can blog just slightly less sporadically again.

One of the recent posts I’ve wanted to comment on is Atom is the New JCR (prompted by Sam Ruby). Adrian Sutton writes:

When the Java Content Repository (JCR) standard first came out it was supposed to bring in a new era of compatibility between content repositories and put an end to the content silo. There was, and still is, a lot of talk about it and just about everyone added JCR compliance to their marketing materials. Unfortunately, that’s mostly where things stopped - the implementation work that followed was generally done was buggy or incomplete and the only viable JCR implementations that I’ve seen have come out of Day Software, who lead the JCR spec effort.

We use JCR inside Galaxy for all our storage needs at the moment. Using it has been an interesting experience to say the least. One of my favorite “features” of JCR has been the fact that you can not have two seperate threads create a child node with the same name at the same time. Which means in our activity log, we can’t add two nodes called “/activity” to “/activities” at the same time.
The main reason we decided to go with JCR is that it supports both simple database type data and file type data via the same interface transparently. I’m not 100% sure it was the right choice though. I had to write an ORM like framework as the one in Jackrabbit seemed pretty immature and I didn’t have time to delve into the rabbit hole of the jcr-mapping module in Jackrabbit. Mine is limited but as least I could figure out how to use it. We’ll be reevaluating this for the future though now that Jackrabbit 1.4 is nearly out.

Adrian continues:

Then along came Atom which is all about remote access and manipulation of data and missing probably 90% of the functionality that JCR offers. It really isn’t a competitor to JCR at all and yet it’s doing more to break down content silos than JCR ever has. Atom support isn’t just being added to the marketing materials, it’s actually shipping and is usable in a lot of places - IBM’s Lotus Connections has Atom APIs to everything and, as best I can tell, only Atom APIs to it’s repository.

I completely agree that JCR isn’t very worthwhile as something that will break down content silos. It does have value as an API to work with data though. Atom is quite limited in the granularity it can work with data (which coincidentally is one of the reasons Web3S exists as well). And you still need to store your data somewhere.

Atom has not replaced JCR it has supplemented it. We use JCR as a content store for Galaxy. I’ve also written a generic JCR content store for AtomPub inside of Abdera. Sure, the vendor promises are probably wrong about the content-silos, but it sure simplifies some things when writing applications - which is what really counts!

Update: David Nuescheler has written a great follow up to this whole discussion.

Also, Jackrabbit 1.4 is out. 

Update: OK folks, lets not get too carried away here. I do want to talk to you still. You don’t need to be afraid to write me. If I feel that your question is better answered on a mailing list, I will tell you so (in a nice way). I understand that there are gray situations where you may not want to write a mailing list and that the mailing lists are not always the best place to get answers. I always try to be very accommodating about this as I value the users of the projects I participate in, the relationships that I’ve established through direct contact, and I also value the direct, honest feedback I might have otherwise never received. This entry was written primarily to be funny! Enjoy it and don’t think about it too much.

Dear XXX,

I appreciate your repeated inquiries which seek to establish a direct support channel with me, the all knowing, Daniel B. Diephouse.

I would like to kindly redirect you to this wonderful thing known as the mailing list. It is a rather new invention (being invented somewhere between the telegraph and today) and has supplied countless users with answers to their questions. By posting your question to the mailing list, you and the community at large will gain many benefits:

• While I will admit I am incredibly smart (and handsome), it seems I do forget things every now and then. Rest assured, there are many people around who can point out the flaws in my otherwise inconsistent logic and point out additional things I might have missed.
• It seems that like myself, there are many people who hang out on the interwebs, have no life, and an infinite amount of spare time. Much to my chagrin, it seems these people have even more infinite time than I and get to your question faster. It makes me feel like just a lowly set of integers in a world of real numbers.
• Recently my friends Larry and Sergey started archiving things for me. Since then, I’ve tended to answer questions more in depth because I can just point people to the previous answers when a repeat question comes up.
• I was trying to keep it from you, but I must confess that in between our conversations I talk to other people as well. And I often answer questions with them too. We share very similar intimate details - exceptions, architecture thoughts, and requirements. Don’t think of it as cheating - think of it is as an open relationship. Why hoard good things to oneself? Personally, I’m a fan of sharing.

I’m sure though that this is not quite reason enough for you as you work for big company X which entitles you to many special concerns and privileges. Working at said company you are surely worried about people knowing you are using an open source project. For example, we wouldn’t want people knowing the stock exchange ran on Linux - it might compromise security. Luckily, there are ways to anonymize yourself today - I think they’re even free. I suggest that you investigate these.

Unless you think I am just talking to you because you work for company X, be sure that it is also partly because you hold a lot of sway in your company. I know your manager really likes you - I heard he gave you a gold star last week! So I have complete faith that X privilege/money will be exchanged somewhere down the line for the upfront personalized support down the line. In the mean time, I really would suggest that you check out the mailing lists while we sort out the details.

Yours truly,

Dan

This is an automated message; please do not reply to this e-mail.

(BTW, If you think this was about you - it probably wasn’t. This is written for 100s of people over the last few years. And if it does describe you, don’t take it personally!)

A fairy dies.

The sad thing is there really isn’t anything better around. Here’s hoping the Spring guys whip it into shape now that its “part of the Spring stack.”

Update: Ben Alex describes a much simplified Spring Security 2.0-M1 release! Looking forward to trying it out. While Miami is sounding quite nice compared to the local Michigan weather, I’m not sure I’ll be able to make it down the Spring Experience for the session.

James Snell:  Wrong. All of this is complex. Technology is complex. It does nobody any good to argue that one particular way of building applications is less complicated than any other way of building applications. WS-* is complex. REST is complex. It’s all complex. Complexity is not the issue. The real issues are things like utility, consistency, accessibility, etc.

Not much I can add to that.

I’m very please to be both attending and speaking at QCon this week. While I’m retiring for the evening, which usually is not my style (damn cold!), I’m looking forward to seeing everyone and meeting lots of faces for the first time tomorrow.

If you’re here and want to meet up, shoot me an email or call the cell (+1.616.318.3474).

Tatu writes:

Developers, meet mr. Jackson: possibly the world’s fastest JSON parser! (and at very least, fastest one written in Java). You heard it here first folks: a new streaming light-weight, and VERY fast JSON-processor (parser+generator) package written from scratch, in Java, is now officially out in the wild. Check out Jackson Hatchery Page for details.

I can’t say enough good things about the software Tatu writes. He’s also the guy behind Woodstox which is bar none the best Java XML parser out there. I’m sure this will end up being the best tool for JSON as well.

Was just writing an email which included a two minute introduction to Java XML performance. I thought I’d quickly replicate it here:

There are a few key areas that I see to XML performance. All can have a huge effect - i.e. you could possibly increase performance 2-10x performance by tweaking any one of these.

1. Your XML parser. By far the fastest here is Woodstox. It is a StAX implementaiton, but it also supports SAX as well.

2. Your databinding implementation. The fastest ones are those that compile optimized xml readers/writers for your domain objects. JiBX is a good example.  SXC (which I wrote) is another. SXC provides compiled readers/writers for your JAXB context, which can speed it up quite a bit. After those two, the JAXB-RI is probably the next fastest. XMLBeans/XStream are mediocre as I recall.

3. The XML representation. Reading everything into a Document object is very memory and resource intensive. Modern databinding frameworks like JAXB, JiBX, etc can turn the XML stream directly into POJOs. Use those if at all possible.