Re: [CODE4LIB] Access to code4lib.org server--how to work it?

2008-03-25 Thread Ross Singer
I don't want the world, I just want your half.
  --Jonathan Rochkind, 2008
more or less

-Ross.

On Tue, Mar 25, 2008 at 8:09 AM, Rob Styles [EMAIL PROTECTED] wrote:
 On 21 Mar 2008, at 16:23, Kevin S. Clarke wrote:
   You and someone else could
   run the planet

  did nobody think the idea that jrochkind and someone else running the
  planet has some comic mileage?

  rob



Re: [CODE4LIB] Access to code4lib.org server--how to work it?

2008-03-25 Thread Karen Coyle

I did, but I assumed I am missing some inside knowledge that would make
it non-comic.

kc

Rob Styles wrote:

On 21 Mar 2008, at 16:23, Kevin S. Clarke wrote:

You and someone else could
run the planet


did nobody think the idea that jrochkind and someone else running the
planet has some comic mileage?

rob




--
---
Karen Coyle / Digital Library Consultant
[EMAIL PROTECTED] http://www.kcoyle.net
ph.: 510-540-7596   skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234



Re: [CODE4LIB] LibraryThing JSON API

2008-03-25 Thread Joe Hourcle

On Tue, 25 Mar 2008, Jay Roos wrote:


Whenever I decide whether to link from our catalog to something external, I
always want to know how I bring the patron back once they've found something
they're interested in. Do you have or have you considered a way to close the
loop and bring someone who followed a link in the catalog back to the
catalog?


One of the few useful things that came from that whole HTML Frames
confusion was the ability to specify a 'target' to links.  if you use a
target name that's not an existing frame, it'll pop up in a new window.
(without requiring javascript to handle the popup).  if you use a
consistent name, it'll recycle the existing window:

   a href='some_url' target='LibraryThing'some text/a

See the HTML specs for more details:
   http://www.w3.org/TR/html401/present/frames.html#h-16.3


There are also some common keywords to use (_top, _blank, _new), which are
widely supported, but I can't find them in the HTML docs.

...

so basically -- someone clicks on the link, it comes in a new window, and
they can close the window to return to where they were.

... the issue with sessions timing out still holds, but as the catalog is
still loaded, you might be able to do something with javascript to warn
the user that they might time out.

-Joe


Re: [CODE4LIB] LibraryThing JSON API

2008-03-25 Thread Nate Vack
On Tue, Mar 25, 2008 at 2:10 PM, Tim Spalding [EMAIL PROTECTED] wrote:

  My big worry is expired sessions. Any ideas how to solve that without
  using a new-session URL?

Long session expiry times?

-Nate


Re: [CODE4LIB] LibraryThing JSON API

2008-03-25 Thread Tim Spalding
I've seen some OPACs with a you are about to be logged out popup.
The LC does this.

I'd think it would be easy to write a JS that simply refreshes the
page, reinvigorating the session.

All of this is idiotic and childish, of course. The only non-library
website I visit now that times out at all is my bank, and it waits
longer than my library does.

Tim

On Tue, Mar 25, 2008 at 3:34 PM, Joe Hourcle
[EMAIL PROTECTED] wrote:
 On Tue, 25 Mar 2008, Jay Roos wrote:

   Whenever I decide whether to link from our catalog to something external, I
   always want to know how I bring the patron back once they've found 
 something
   they're interested in. Do you have or have you considered a way to close 
 the
   loop and bring someone who followed a link in the catalog back to the
   catalog?

  One of the few useful things that came from that whole HTML Frames
  confusion was the ability to specify a 'target' to links.  if you use a
  target name that's not an existing frame, it'll pop up in a new window.
  (without requiring javascript to handle the popup).  if you use a
  consistent name, it'll recycle the existing window:

 a href='some_url' target='LibraryThing'some text/a

  See the HTML specs for more details:
 http://www.w3.org/TR/html401/present/frames.html#h-16.3


  There are also some common keywords to use (_top, _blank, _new), which are
  widely supported, but I can't find them in the HTML docs.

  ...

  so basically -- someone clicks on the link, it comes in a new window, and
  they can close the window to return to where they were.

  ... the issue with sessions timing out still holds, but as the catalog is
  still loaded, you might be able to do something with javascript to warn
  the user that they might time out.

  -Joe




--
Check out my library at http://www.librarything.com/profile/timspalding


Re: [CODE4LIB] LibraryThing JSON API

2008-03-25 Thread Sutherland, Michael
My big worry is expired sessions. Any ideas how to solve that without
using a new-session URL?

Tim

You also pass along a session id and if the user times out, she could
log back in and continue the previous session.

As for,

One of the few useful things that came from that whole HTML Frames
confusion was the ability to specify a 'target' to links.  if you use a
target name that's not an existing frame, it'll pop up in a new window.
(without requiring javascript to handle the popup).  if you use a
consistent name, it'll recycle the existing window:

a href='some_url' target='LibraryThing'some text/a

See the HTML specs for more details:
http://www.w3.org/TR/html401/present/frames.html#h-16.3


There are also some common keywords to use (_top, _blank, _new), which
are
widely supported, but I can't find them in the HTML docs.

I would not recommend this because it is not standards compliant. W3C
standards reserve only four names for the target attribute _blank,
_parent, _self, and _top.  Some developers also use _new instead
of _blank as the value for the target attribute to open a link in a
new window, although W3C standards do not define that as a target name,
thus browsers may ignore it or treat it as a synonym for _blank.
Browser settings can override all of this.

Michael Sutherland


Re: [CODE4LIB] LibraryThing JSON API

2008-03-25 Thread Tim Spalding
We've had this fight on Code4Lib before, but it deserves mentioning
that no browser breaks this, and no browser developer is going to
break it. It's widely used—for more widely used than any number of
standards-compliant techniques that don't work and probably never
will. To care about this in the context of today's mainstream OPACs is
like keeping your fingernails clean after a nuclear attack.

  I would not recommend this because it is not standards compliant. W3C
  standards reserve only four names for the target attribute _blank,
  _parent, _self, and _top.  Some developers also use _new instead
  of _blank as the value for the target attribute to open a link in a
  new window, although W3C standards do not define that as a target name,
  thus browsers may ignore it or treat it as a synonym for _blank.
  Browser settings can override all of this.