I added in support for http://ipinfodb.com/ (see bottom of README) which might be better than Google's api, although you need to register for an API key. You might want to give that a shot.

I thought about doing that. I've used a lot of coffeescript in the past, but I just didn't see it being a big advantage here. The biggest issue with using CoffeeScript here is that I wanted control over the syntax as I wanted to have less code. CoffeeScript (generated) really creates more code than what it's worth.

I get it. Thanks for writing it.

Official demo: http://codejoust.github.com/session.js/

No. And the recently-posted paid visitor.js site does have a few advantages, most being that this is using pure javascript, while they have the server side doing most of the heavy lifting.

In that case, this implementation really should have a different name. It's confusing to have two competing implementations share the same name, and it may be a trademark violation.

>"and it may be a trademark violation."

"visitor.js" isn't distinct in the field, particularly as it's descriptive and of a common form, I'd warrant it's not novel either.

That doesn't mean that you wouldn't be sued for using it just that any sane TM office shouldn't allow it to be registered and that a sane IP judge should dismiss a case brought against it's use as passing off. The law isn't sane of course ....

I think it's reasonable to use the same name if the scope is largely co-terminous.

It's because the scope is co-terminous that having different names is so important. IANAL, but trademarks don't have to be distinct or novel to be legitimate. They are allowed to be descriptive (like Windows or iPhone).

The fork of OpenOffice.org was named LibreOffice, because it would be unfair to name a competing product with the same name. I'm glad the author of this library has decided to do the same.

First up, "iphone" is definitely not descriptive, it's abstract, a made up word. "touchPhone" would be descriptive. "Windows", well ... it's a generic term now but at the time, despite it being to some extent descriptive of a WIMP system it was arguably a distinctive term for an OS (but I'm surprised it was allowed).

OpenOffice.org is interesting because they previously named the project "Open Office" and suffered trademark problems and had to be very careful to use the full name of the project. But had the former project been called "Computer Office Suite" then trademark issues wouldn't have arisen because that's not a distinctive mark and so couldn't be protected, it's descriptive anyone selling such software could use that description.

It's not unfair to use an identical descriptive name for things that serve the same function - for example Microsoft and Apple both sell something that they use the term "Operating System" to describe. OS is a descriptve term that is expected to be used in the field and so can't be a trademark, it doesn't serve to indicate origin.

I'd argue that visitor.js is an expected name for a piece javascript that logs visitors in some way, it's not distinctive of origin. Moreover it is descriptive of the function of the code. Kinda like having an ad loader that's called ads.js.

FWIW, and I've not been paying too much attention (!), only one of the pieces of code labelled visitor.js appears to be a product.

I believe the earlier comments have merit, thus I've renamed the library.

Google provides it as an extra for the JSAPI, no telling how long it will last, though.

Developers should have learned by now not rely on Google for anything. Once all competing paid services (just like visitor.js) get driven out of business by Google's free service, you can count on Google doing the ol' bait and switch, by taking down the free API, erecting a paywall leaving themselves with a monopoly.

I liked the idea, and had already needed parts of such a library, so I put together some stuff and made a free/open-source version.

https://github.com/codejoust/visitor.js

Whoa! Super impressed you turned this out so quickly. You should post it as a 'Show HN' story!

Also, props for renaming it to session.js (I think it's unfair to use their name)

This might spur the visitor.js guys to release part of their codebase as open source and continue to provide a paid service with extra support and features etc.

I built a open-source version similar to this library for my own use using javascript browser checks and the google jsapi geocoding. It's on github at https://github.com/codejoust/visitor.js.

I've done a considerable amount of work in subprocess. It's API isn't amazing, but it does have quite a few great features and once you spend a little time with it really isn't too bad. Some of the piping features, along with shell arguments work quite well.

Winning: http://chattanooga.jpg.to/ It works pretty well, although there are some oddball results.

How about running the facebook javascript in a sandbox? Such as proxying the document.createElement and document.getElements* methods for the initial script while breaking it for everything else?

That's a good idea, and we actually thought about that. But assuming we need those APIs, what's to keep them from calling our wrappers around them?

Put another way, how do we determine if the caller of some of our js is malicious or is us?

It just needs to be non-predictable. Give the wrapper object and ALL his methods a random name for every session.