Questions about libx

[Jeremy Dunck]

I'm not sure if I'm the intended audience for LibX, so tell me if I'm
charging in the wrong direction.
(Who is LibX for?)

I can see that libx is useful, but I don't have a strong affiliation
with any particular library.

Would you be open to enhancements allowing libx to use any and all of
a list of libraries?

This would take the config-file-compiled-to-xpi design in a different
direction.  I think a runtime catalog of config files, with 1 or more
selected as active, would be nice.

No?
---

Seperately, it looks like you're putting a lot of functions into the
global chrome namespace.  All extensions share the same space, so LibX
will not play nicely with other extensions that include, for example,
a function named newpage.

(This also means that two installed editions of LibX may not work well
together, depending on what replacements you're making based on the
edition configs.)

This is commonly addressed by either using a unique-y prefix, nested
namespaces or closures.

...I haven't done any testing on this, so feel free to tell me to take a hike.

--

Lastly, regarding agressive AJAX when injecting cues, this goes back
to expected common uses.  If you hope for LibX to become very commonly
used, I'd say no, don't go too rich since you'll burden people.  And
local caching won't do much good since repeated lookups of the same
piece won't happen a lot.  You -could- have a central caching proxy
service, but that'd have privacy concerns.

...BookBurro solved this nicely by only fetching upon user action, but
making it -very- easy to invoke that action.

Cheers,
  Jeremy
_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

[Godmar Back]

[ some of my reply is related to arcane Firefox/Javascript issues,
LibX users may want to skip those parts.  Other parts relate to
strategy issues for LibX. ]

On 4/28/06, Jeremy Dunck <jdunck@...> wrote:
> I'm not sure if I'm the intended audience for LibX, so tell me if I'm
> charging in the wrong direction.
> (Who is LibX for?)
>

LibX is for people using a library who frequently need access to that
library's resources: students, professors, and the general public.

> I can see that libx is useful, but I don't have a strong affiliation
> with any particular library.
>
> Would you be open to enhancements allowing libx to use any and all of
> a list of libraries?
>

See also http://libx.org/faq.html#QL1a

2.  Why not let users adapt the toolbar themselves?

We felt that an extension that supports a community of library users
should be offered by that community's library.

That said, since LibX is open source, developers can add this
functionality if they wish. In addition, end users can create their
own editions without consulting with their library.
---

You should look at the homepage libraries have created for their
editions of LibX. Go to libx.org -> Editions and click on those pages.

> This would take the config-file-compiled-to-xpi design in a different
> direction.  I think a runtime catalog of config files, with 1 or more
> selected as active, would be nice.
>
> No?

That's certainly possible, but would require a near-total rewrite.
We'll put our energy into the web interface, I think, because it will
look nearly
identical from a user's perspective.  (There's isn't much difference
between your idea: download libx, scroll through a list of catalogs,
press ok; vs. ours: scroll through a list of catalogs, press ok,
download libx.)  The only difference is when someone frequently wants
to change their entire configuration - an infrequent case.

Also, we'd like libraries to test their edition and give the user a
reasonable degree of assurance that what they're running was vetted by
someone who knows how the library catalog should behave. As an
example, you may wish to download a test edition, say MIT's:
http://libx.org/libx/src/editions/libxtestedition.php?edition=mit and
go through the check list (or at least some of it) shown on that page.
True, this could be accomplished by having a checkmark next to a
configuration, however, this would be fragile in the face of other
code changes. In the current approach the edition is complete, tested
snapshot of all of LibX's code.
This would not be the case if new configurations could be loaded into
an existing installation, because new configurations are not tested
with the code base a user may have installed.

> ---
>
> Seperately, it looks like you're putting a lot of functions into the
> global chrome namespace.  All extensions share the same space, so LibX
> will not play nicely with other extensions that include, for example,
> a function named newpage.
>
> (This also means that two installed editions of LibX may not work well
> together, depending on what replacements you're making based on the
> edition configs.)

Yes, see FAQ:

# Can I have two editions installed simultaneously?

No, technical limitations in Firefox 1.0 and 1.5 prevent that. You can
however create different profiles if you wish to use different
editions.

>
> This is commonly addressed by either using a unique-y prefix, nested
> namespaces or closures.
>
> ...I haven't done any testing on this, so feel free to tell me to take a hike.
>

I didn't intend Firefox would be broken like this forever, I truly
expected them to adopt a modern extension model where each extension
would be given its own namespace for its javascript.

But this doesn't appear to be happening, so we've started giving a
libx prefix to new functions we added, e.g.
function libxGetProperty(prop, args) {
function libxInitializeCatalog(cattype, catprefix)
function libxInitializeCatalogs()
function libxInit()

There's still some legacy, as in many older (> 6 months) extensions.

Some functions already live in closures, such as the DoForURL actions
in libxdfu.js.

I didn't know JavaScript supported nested namespaces, could you tell
me how do use them? Or do you mean I should attach my functions to
some Object I create?

Is there an easy way to put multiple .js files in their own, nested namespace?

> --
>
> Lastly, regarding agressive AJAX when injecting cues, this goes back
> to expected common uses.  If you hope for LibX to become very commonly
> used, I'd say no, don't go too rich since you'll burden people.  And
> local caching won't do much good since repeated lookups of the same
> piece won't happen a lot.  You -could- have a central caching proxy
> service, but that'd have privacy concerns.
>
> ...BookBurro solved this nicely by only fetching upon user action, but
> making it -very- easy to invoke that action.
>

I too have doubts that the "this book is due on" entry in Amazon would
be of much benefit. It has a certain coolness factor, true, but users
don't browse Amazon and constantly ask the question whether the book
is on the shelves. If they need to know, they can click; there's also
the question of screen real-estate.

However, there are other places where AJAX will be more appropriate.
For instance, in OpenURL resolution, you often have OpenURL resolvers
that simply place a link to some other database (say Infogale) in
their results. The next thing the user will invariably do is click on
that link, we may as well ajax the result for them.

 - Godmar
_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

[Godmar Back]

[ this email is more on the "how should LibX be built/deployed" issue.
If you're subscribed to LibX because you're maintaining an edition,
you can ignore it. We should probably create an libx-announce mailing
list at some point.]

Jeremy,

I'd like to reemphasize the importance of the point I'm making below
(even before you get a chance to reply ;-): that it is of tremendous
value to the user that they download a .xpi file that was tested as is
in its entirety.

By contrary example, one of our team member recently taught a class on
Firefox, and tried to include some Greasemonkey scripts to show off
GM. We went to userscripts.org and looked for some cool scripts. The
vast majority of scripts on that site did not work, or we couldn't
figure out how to make them work (before you suspect incompetence, I
have written and occasionally write GM scripts myself for various
ad-hoc tasks, so I'm reasonably familiar with it. I gave up after 2, 3
minutes for each script.)

Such a degree of robustness would be unacceptable to many librarians -
they definitely did not want to put their name (or logo) on such a
piece of software.

As far as your criticism of libx's internal goes, it is fully
accepted. We have some cool stuff we'll include in the current code
base, but I can see a complete namespace etc. cleanup in the near
future unless someone beats us to it.

 - Godmar

On 4/28/06, Godmar Back <godmar@...> wrote:

>
> Also, we'd like libraries to test their edition and give the user a
> reasonable degree of assurance that what they're running was vetted by
> someone who knows how the library catalog should behave. As an
> example, you may wish to download a test edition, say MIT's:
> http://libx.org/libx/src/editions/libxtestedition.php?edition=mit and
> go through the check list (or at least some of it) shown on that page.
> True, this could be accomplished by having a checkmark next to a
> configuration, however, this would be fragile in the face of other
> code changes. In the current approach the edition is complete, tested
> snapshot of all of LibX's code.
> This would not be the case if new configurations could be loaded into
> an existing installation, because new configurations are not tested
> with the code base a user may have installed.
>

_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

[Jeremy Dunck]

On 4/28/06, Godmar Back <godmar@...> wrote:
> LibX is for people using a library who frequently need access to that
> library's resources: students, professors, and the general public.

OK, it wasn't clear to me that the site is largely directed at
librarians interested in packaging an edition for their patrons.

> > I can see that libx is useful, but I don't have a strong affiliation
> > with any particular library.
...
> We felt that an extension that supports a community of library users
> should be offered by that community's library.
>
> That said, since LibX is open source, developers can add this
> functionality if they wish. In addition, end users can create their
> own editions without consulting with their library.

The way I read that is "we're doing this, and if you want something
different feel free to fork it."   I don't want to fork it, so I guess
I'm happy with what you have.  ;-)

I understand the need you're trying to address (making it as easy as
possible for non-tech patrons and encouraging affiliation with a
particular library.  Maybe I'm unusual in being a patron at 4-5
libraries?  (I'm aware of inter-library loans, but still am willing to
drive a few extra miles to save that hassle.)

Incidentally, sorry for missing the Librarian section of the FAQ.  I'm
not one of those, but it does indeed answer several of my questions.
:)

> You should look at the homepage libraries have created for their
> editions of LibX. Go to libx.org -> Editions and click on those pages.

Yeah, again, the "edition" piece didn't fit with my assumptions, but
it makes sense given your goal.

> (There's isn't much difference
> between your idea: download libx, scroll through a list of catalogs,
> press ok; vs. ours: scroll through a list of catalogs, press ok,
> download libx.)  The only difference is when someone frequently wants
> to change their entire configuration - an infrequent case.

Well, in any case we're talking about a small convenience over
manually copy stuff into your-favorite-library's OPAC.  I think no one
manually does the price comparisons that BookBurro enables in a click.

I think supporting search over multiple libraries in a streamlined UI
is useful, but as I said, I'm probably unusual.

> This would not be the case if new configurations could be loaded into
> an existing installation, because new configurations are not tested
> with the code base a user may have installed.

I understand.

> > (This also means that two installed editions of LibX may not work well
> > together, depending on what replacements you're making based on the
> > edition configs.)
...
> I didn't intend Firefox would be broken like this forever, I truly
> expected them to adopt a modern extension model where each extension
> would be given its own namespace for its javascript.

Oh, has LibX been around long?  I had the impression that it was new.
How long was VTBar before becoming LibX?

I had the same feeling when I first saw this issue; an early release
of GM had a bug in its XUL chrome definition and broken a significant
hunk of Firefox in the process.  But actually, extensions -can- have
their own namespace.  The main problem with firefox extension
development is poor documentation and a lack of known best-practices.

However, Google's Blogger Web Comments (developed while rubbing elbows
with Firefox contributors) does this sandboxing.
http://dl.google.com/firefox/google-webcomments.xpi

(I don't claim to fully understand the code, but
./components/bootstrap.js and G_JSModule are the places to start.)

> But this doesn't appear to be happening, so we've started giving a
> libx prefix to new functions we added, e.g.
> function libxGetProperty(prop, args) {
> function libxInitializeCatalog(cattype, catprefix)
> function libxInitializeCatalogs()
> function libxInit()

While you're at it, you might generate those with the edition label so
that you can run two editions together.  ;-)

libxInit becomes libx_mit_Init and libx_rit_Init.

> I didn't know JavaScript supported nested namespaces, could you tell
> me how do use them? Or do you mean I should attach my functions to
> some Object I create?
>
> Is there an easy way to put multiple .js files in their own, nested namespace?

BWC shows one way (subscripts), but the latter works, too.  See
"Isolating your code through Namespaces" here:
http://13thparallel.org/archive/coding-for-portability1/

Cheers,
  Jeremy
_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

[Jeremy Dunck]

On 4/28/06, Godmar Back <godmar@...> wrote:
> The
> vast majority of scripts on that site did not work, or we couldn't
> figure out how to make them work (before you suspect incompetence, I
> have written and occasionally write GM scripts myself for various
> ad-hoc tasks, so I'm reasonably familiar with it. I gave up after 2, 3
> minutes for each script.)

I'm generally not quick to suspect incompetence, or even hold it
against people.  I am not well-skilled in all areas of human
knowledge, and so try not to criticise others for not being expert in
my pet interests.  ;-)

Even so, the issue you raise is well-known in GM-land.  There was a
major transition in the security model of GM such that many scripts
written under the old model don't work under the new model.  Mark
Pilgrim probably knows this best-- he had to port many scripts over
when writing Greasemonkey Hacks.

Lots of people see GM user scripts as shell scripts for the web, so
that it's no major hardship when one breaks-- just write a new one of
fix the old one.  This also implies a community assumption-- that
people using Greasemonkey are, largely, javascript developers.

And so I think the trouble with finding working user scripts is
largely a matter of bad presentation-- userscript.org should make it
easy to flag dead scripts and to update them with fixes.  Sadly, I've
never gotten around to that issue.

All that said, the issue is largely a cultural one, and it would be
entirely possible to have a well-tested set of userscripts as a
deployment unit.

> Such a degree of robustness would be unacceptable to many librarians -
> they definitely did not want to put their name (or logo) on such a
> piece of software.

I'm sure there are hundreds of working user scripts on us.o, but it's
not obvious which are which.  That's kind of the point-- there are two
things at work here.  There's the perception of GM's fragility and in
that sense, I think LibX is really in the same ballpark.  You're still
depending on DOM manipulation on a known tree-- you're just less
likely to break since OPAC upgrades are few and far between.  A user
script coded against an OPAC would be similarly stable.  ;-)

The second thing is that you're making a domain-specific page
modifier, and (as I hope I've made clear) I think that's useful.
(I also think it'd be nice if an library-related code library came out
of this.  Dealing with the various OPAC flavors, xISBN, OpenURL, and
COiNS could, I think, be usefully abstracted for extensions other than
LibX.)

> As far as your criticism of libx's internal goes, it is fully
> accepted.

I hope it's clear that I'm happy to see LibX, and that any criticism
I'm offering is rooted in my desire to see LibX's success.

I'd like to see the search interaction more stream-lined, too, but I
haven't formed a suggestion yet.   Copious free time...
_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

[LibX Project]

Hi Jeremy--

"Maybe I'm unusual in being a patron at 4-5 libraries?"

I am usually a patron and/or affiliated with more than one library at any given time.  We're aware that many people are using more than one library at a time... ie if they are a student they may use their school library and the local public library.

"Oh, has LibX been around long?  I had the impression that it was new.
How long was VTBar before becoming LibX?"

VTBar was first developed last summer (2005) and became LibX last fall.

We're planning a code clean-up soon... if there are better ways to address the namespace issue we'll take that into account.

Thanks,
Annette

On 4/28/06, Jeremy Dunck <jdunck@...> wrote:

On 4/28/06, Godmar Back <godmar@...> wrote:
> LibX is for people using a library who frequently need access to that
> library's resources: students, professors, and the general public.

OK, it wasn't clear to me that the site is largely directed at
librarians interested in packaging an edition for their patrons.

> > I can see that libx is useful, but I don't have a strong affiliation
> > with any particular library.
...
> We felt that an extension that supports a community of library users
> should be offered by that community's library.
>
> That said, since LibX is open source, developers can add this
> functionality if they wish. In addition, end users can create their
> own editions without consulting with their library.

The way I read that is "we're doing this, and if you want something
different feel free to fork it."   I don't want to fork it, so I guess
I'm happy with what you have.  ;-)

I understand the need you're trying to address (making it as easy as
possible for non-tech patrons and encouraging affiliation with a
particular library.  Maybe I'm unusual in being a patron at 4-5
libraries?  (I'm aware of inter-library loans, but still am willing to
drive a few extra miles to save that hassle.)

Incidentally, sorry for missing the Librarian section of the FAQ.  I'm
not one of those, but it does indeed answer several of my questions.
:)

> You should look at the homepage libraries have created for their
> editions of LibX. Go to libx.org -> Editions and click on those pages.

Yeah, again, the "edition" piece didn't fit with my assumptions, but
it makes sense given your goal.

> (There's isn't much difference
> between your idea: download libx, scroll through a list of catalogs,
> press ok; vs. ours: scroll through a list of catalogs, press ok,
> download libx.)  The only difference is when someone frequently wants
> to change their entire configuration - an infrequent case.

Well, in any case we're talking about a small convenience over
manually copy stuff into your-favorite-library's OPAC.  I think no one
manually does the price comparisons that BookBurro enables in a click.

I think supporting search over multiple libraries in a streamlined UI
is useful, but as I said, I'm probably unusual.

> This would not be the case if new configurations could be loaded into
> an existing installation, because new configurations are not tested
> with the code base a user may have installed.

I understand.

> > (This also means that two installed editions of LibX may not work well
> > together, depending on what replacements you're making based on the
> > edition configs.)
...
> I didn't intend Firefox would be broken like this forever, I truly
> expected them to adopt a modern extension model where each extension
> would be given its own namespace for its javascript.

Oh, has LibX been around long?  I had the impression that it was new.
How long was VTBar before becoming LibX?

I had the same feeling when I first saw this issue; an early release
of GM had a bug in its XUL chrome definition and broken a significant
hunk of Firefox in the process.  But actually, extensions -can- have
their own namespace.  The main problem with firefox extension
development is poor documentation and a lack of known best-practices.

However, Google's Blogger Web Comments (developed while rubbing elbows
with Firefox contributors) does this sandboxing.
http://dl.google.com/firefox/google-webcomments.xpi

(I don't claim to fully understand the code, but
./components/bootstrap.js and G_JSModule are the places to start.)

> But this doesn't appear to be happening, so we've started giving a
> libx prefix to new functions we added, e.g.
> function libxGetProperty(prop, args) {
> function libxInitializeCatalog(cattype, catprefix)
> function libxInitializeCatalogs()
> function libxInit()

While you're at it, you might generate those with the edition label so
that you can run two editions together.  ;-)

libxInit becomes libx_mit_Init and libx_rit_Init.

> I didn't know JavaScript supported nested namespaces, could you tell
> me how do use them? Or do you mean I should attach my functions to
> some Object I create?
>
> Is there an easy way to put multiple .js files in their own, nested namespace?

BWC shows one way (subscripts), but the latter works, too.  See
"Isolating your code through Namespaces" here:
http://13thparallel.org/archive/coding-for-portability1/

Cheers,
  Jeremy
_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

[Ross Singer]

On 4/28/06, Jeremy Dunck <jdunck@...> wrote:

I'm sure there are hundreds of working user scripts on us.o, but it's
not obvious which are which.  That's kind of the point-- there are two
things at work here.  There's the perception of GM's fragility and in
that sense, I think LibX is really in the same ballpark.  You're still
depending on DOM manipulation on a known tree-- you're just less
likely to break since OPAC upgrades are few and far between.  A user
script coded against an OPAC would be similarly stable.  ;-)

This is a very good point (and why, ultimately, I gave up on development of WAG the Dog).  Certainly the widespread adoption of parseable cues, such as COinS or microformats, would help considerably.  Until then, it's constantly a matter of keeping up with what's breaking (and writing new scrapers for new services that appear in the wild).  I found I didn't have the energy or the interest to do this and the introduction of LibX gave me an easy out :).

The second thing is that you're making a domain-specific page
modifier, and (as I hope I've made clear) I think that's useful.
(I also think it'd be nice if an library-related code library came out
of this.  Dealing with the various OPAC flavors, xISBN, OpenURL, and
COiNS could, I think, be usefully abstracted for extensions other than
LibX.)

I would really love to see something like this.  The nice part of the library world (well, it's actually very frustrating, but this is one advantage) is that the low number of actual vendors means that creating libraries for services that don't have a standards based interface for is fairly small.  Such a clearinghouse might serve the double purpose of informing people how to actually implement (and use) standards based approaches to their services.

Then again, nobody may contribute to it and it will wither on the vine, like so many other initiatives in the past.  However, I'm encouraged by the work that Ryan Eby, David Walker and Rob Casson have done to form a similar community around the III XMLOPAC:  http://wiki.lib.muohio.edu/xmlopac/index.php/Main_Page

It would be nice to see similar efforts for other products.

-Ross.

_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

[Jeremy Dunck]

On 4/28/06, Ross Singer <ross.singer@...> wrote:
>  Then again, nobody may contribute to it and it will wither on the vine,
> like so many other initiatives in the past.

Hmm.  I started to write that there needs to be a library planet, but
I guess this is it:
http://planet.code4lib.org/

I didn't know about it until searching just now.  :)

Who do I need to bug to get atom support over there?
...
I often wonder what it would be like for the patron model to return,
allowing people to spend their time doing things they are interested
in most of the time, rather than when their lives allow them a few
minutes' work.
_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

[Godmar Back]

On 4/28/06, Jeremy Dunck <jdunck@...> wrote:
> I think supporting search over multiple libraries in a streamlined UI
> is useful, but as I said, I'm probably unusual.
>

That's already possible - LibX supports multiple catalogs in one
edition (although only one OpenURL resolver/proxy right now, but we
might change that.) Also, right now, the context menu only goes to the
primary catalog (if multiple are configured), and cues are pointing to
the primary catalog - but that's on our list of things to fix so the
context menu/cues use the currently selected catalog.

You can build an edition - we would even host a "Jeremy Dunck" edition
if you test it.

Once the edition maker interface is in place, anybody can do just that.

 - Godmar
_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

[Godmar Back]

[ more LibX technology discussion - I'm writing separate emails for
different issues. ]

On 4/28/06, Jeremy Dunck <jdunck@...> wrote:
>
> things at work here.  There's the perception of GM's fragility and in
> that sense, I think LibX is really in the same ballpark.  You're still
> depending on DOM manipulation on a known tree-- you're just less
> likely to break since OPAC upgrades are few and far between.  A user
> script coded against an OPAC would be similarly stable.  ;-)
>

I disagree to a point.  DOM-dependent web localization is just one
aspect of LibX that has this degree of fragility, the other aspects do
not. OpenURL is a standard around 5 years or so, and library's don't
change their ILS providers more than once a year.

Currently, for instance, in LibX 1.0.2, the New York Times cue is
broken because the Times changed their book review layout. But this
does not mean LibX is broken.

> The second thing is that you're making a domain-specific page
> modifier, and (as I hope I've made clear) I think that's useful.
> (I also think it'd be nice if an library-related code library came out
> of this.  Dealing with the various OPAC flavors, xISBN, OpenURL, and
> COiNS could, I think, be usefully abstracted for extensions other than
> LibX.)
>

The OpenURL access, the catalog support are written in separate .js
files using relatively clean classes & objects. The OpenURL part even
uses programming-by-difference inheritance. The only grave deficiency
is the global namespace issue.

 - Godmar
_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

[Ross Singer]

Well, planet.code4lib.org is less of a library planet than a "library developer" planet.  A library planet would be have way too many feeds.

It has atom an atom feed:
http://code4lib.org/planet/atom.xml

Is that what you mean?

Still, although that's an incredibly good resource for information, it's not a terribly good resource for code.

I think there's some desire to make http://www.code4lib.org/ serve that sort of purpose, but I can't remember, for sure.

Actually, you might want to check out the whole code4lib community.  It's pretty active, we're just not good at compiling things :)

-Ross.

On 4/28/06, Jeremy Dunck <jdunck@...> wrote:

On 4/28/06, Ross Singer <ross.singer@...> wrote:
>  Then again, nobody may contribute to it and it will wither on the vine,
> like so many other initiatives in the past.

Hmm.  I started to write that there needs to be a library planet, but
I guess this is it:
http://planet.code4lib.org/

I didn't know about it until searching just now.  :)

Who do I need to bug to get atom support over there?
...
I often wonder what it would be like for the patron model to return,
allowing people to spend their time doing things they are interested
in most of the time, rather than when their lives allow them a few
minutes' work.

_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx

[Godmar Back]

Two meta comments about code libraries, LibX etc.

I believe that there is already a large community that shares code
(code4lib, etc.) and that's wonderful. LibX wants to be part of it,
and has the necessary license and transparency in the development
process for that.

However, a specific "code repository" - where people upload code for
others to download, maybe as module, is doomed to failure (I know of
no successful open source project that followed this model and was
succesful.)

Rather, code needs to be used in order to live and not rot. This is
what we hope to accomplish with LibX. As such, if someone wanted to
use the infrastructure to implement WAG the dog type services, or any
unAPI stuff, we would be happy to include that in LibX so it would be
continously used by libraries. People can also use parts of LibX or
contribute parts to it, or take parts from it.  But taking out parts
of LibX and putting them in reusable form with the hope that someone
might use would not be a wise investment of time for us. (But suppose
somebody were to take the catalog code or openurl, package it into a
library, then use it for another project, we'd certainly change LibX
to use that library as well.)

 - Godmar

On 4/28/06, Ross Singer <ross.singer@...> wrote:

> On 4/28/06, Jeremy Dunck <jdunck@...> wrote:
>
>
>
> > I'm sure there are hundreds of working user scripts on us.o, but it's
> > not obvious which are which.  That's kind of the point-- there are two
> > things at work here.  There's the perception of GM's fragility and in
> > that sense, I think LibX is really in the same ballpark.  You're still
> > depending on DOM manipulation on a known tree-- you're just less
> > likely to break since OPAC upgrades are few and far between.  A user
> > script coded against an OPAC would be similarly stable.  ;-)
>
>
>  This is a very good point (and why, ultimately, I gave up on development of
> WAG the Dog).  Certainly the widespread adoption of parseable cues, such as
> COinS or microformats, would help considerably.  Until then, it's constantly
> a matter of keeping up with what's breaking (and writing new scrapers for
> new services that appear in the wild).  I found I didn't have the energy or
> the interest to do this and the introduction of LibX gave me an easy out :).
>
>
> > The second thing is that you're making a domain-specific page
> > modifier, and (as I hope I've made clear) I think that's useful.
> > (I also think it'd be nice if an library-related code library came out
> > of this.  Dealing with the various OPAC flavors, xISBN, OpenURL, and
> > COiNS could, I think, be usefully abstracted for extensions other than
> > LibX.)
>
>
>  I would really love to see something like this.  The nice part of the
> library world (well, it's actually very frustrating, but this is one
> advantage) is that the low number of actual vendors means that creating
> libraries for services that don't have a standards based interface for is
> fairly small.  Such a clearinghouse might serve the double purpose of
> informing people how to actually implement (and use) standards based
> approaches to their services.
>
>  Then again, nobody may contribute to it and it will wither on the vine,
> like so many other initiatives in the past.  However, I'm encouraged by the
> work that Ryan Eby, David Walker and Rob Casson have done to form a similar
> community around the III XMLOPAC:
> http://wiki.lib.muohio.edu/xmlopac/index.php/Main_Page
>
>  It would be nice to see similar efforts for other products.
>
>  -Ross.
>
>
>

_______________________________________________
Libx mailing list
Libx@...
http://mozdev.org/mailman/listinfo/libx