[LibX] cue design alternatives (was: broken embedded cues in Amazon.com)
godmar at gmail.com
Wed May 28 07:59:08 PDT 2008
On Wed, May 28, 2008 at 7:04 AM, Ross Singer <rossfsinger at gmail.com> wrote:
> On Tue, May 27, 2008 at 12:28 PM, Godmar Back <godmar at gmail.com> wrote:
>> Second, as I pointed out, we share your concern and are close to
>> deploying a technological solution. From a technology point of view,
>> unfortunately, the cues aren't "basic stuff" --- they fundamentally
>> depend on decisions beyond our control.
> There is actually a way to regain control (at least from the
> perspective of not having to update the LibX editions locally), but I
> understand if the LibX project doesn't really want to go there.
> Basically, it would mean some centralized translator service that
> turns Amazon into a normalized document (or API response or
> something), so changes at Amazon (or wherever) would only need to be
> updated at a single point (much like Dapper or Yahoo Pipes).
> However, this requires a shift in support and resources that would
> most likely just complicate things.
I'd like to make sure we're not missing a technological alternative
here. We had previously discussed server-side and proxy-style (like
WAG) solutions for web localization and adaptation, but discarded them
for a) lack of scalability, b) lack of seamless browser integration,
and c) need to maintain a server. (With careful design and good use of
resources, and judicious use of free, existing services, the last
reason can probably be overcome, so let's ignore that for now.)
The idea behind automatic updates is to have the required central
point on the server hosting the localization script (this will for now
be libx.org, but our design will allow us to open this to trusted 3rd
parties quickly). Each client will poll for updated scripts every so
often. This scheme is similar to the subscription scheme used by other
client-side mashup tools, such as Intel MashMaker (which unlike LibX
is FF-only, not publicly available and not open source.)
My understanding is that services such as Yahoo Pipes or Dabber help
syndicate websites not designed for syndication by turning them into
some consumable service. LibX cues (ours and 3rd party) can become
consumers of such services, Ross's Jangle hopefully soon included.
In the example we're discussing in this thread, though, we're not
consuming the Amazon website, we're enriching it while the user visits
it. At an abstract level, we need to store the information to create
the composite, or mashup, from the components that form the original
amazon.com view and whatever we wish to add. Our design assumes that
the original page in all its sophistication will form the majority of
what the users sees while LibX adds (small) parts to it.
In short, I don't see how a mashup based on the amazon.com site could
be helped by having a centrally normalized version of the amazon.com
site. How would that work? One approach would be to normalize, enrich,
then render. The question here is where to normalize (on the client?
on a proxy server?) and how to ensure that the enriched page renders
like the original Amazon page. I'm rather skeptical that this approach
is technologically feasible at this point, but am open to learning new
More information about the Libx