> If you have a structure. A->C, B->C then you might actually want back
> functionality. Otherwise you have to create two copies of C (A<-C1, B<-C2)
> wasting bandwidth and space for what is essentially the same page.
This makes no sense to me whatsoever. You don't need more than one
copy of C at all, just keep referencing C from wherever you call it. This is
how the web works. I don't see why you need to duplicate information just to
link to it from two different places.
> I believe this is actually what the AvantGo people had in mind with the
> pods:// syntax.
Actually, pods was designed for doing disconnected form validation,
and generating dynamic pages in response to user input on the client device
proper, not for hijacking standard webpage navigation elements. This
developer guide might provide more insight:
http://www.avantgo.com/doc/archive/36/pods36.pdf
> However, some functionality, like client-side form validation, is nice to
> have, though.
..and incredibly easy to exploit. I'd love to see a list of sites
that are still using this antiquated approach to insecure form validation.
> No, but we should try to support the features that are easy to implement.
> It seems to me that a Back function code isn't difficult to add. The
> Viewer can already render links and it has back/forward/home
> functionality. It shouldn't be too difficult to combine this.
To the end user, they tap a link, and are brought back to the page
from whence they came. None of this involves parsing AvantGo's proprietary
pods:// style linking mechanisms. Since we already know what page the back
_arrow_ brings us to, it's a simple matter to write that record id into the
element that contains the proprietary pods:// string. It can be a literal
search and replace (and IMHO, it should be, we shouldn't be "parsing" these
for anything other than immediate replacement/removal).
> Complicated as FMX may be, designers do produce some nice content with it
> once in a while.
Until it is 100% fully open, or browsers support it internally, it
will still remain a third-party add-on, and not used by that many people.
Does it work in text-mode browsers?
Here's yet another place I see amateurs butchering their userbase by
replacing standard navigation elements with Javascript dropdown menus, or
using Shockwave for basic navigation elements. If I can't navigate the site
using a browser with all scripting features (and color) turned off, then I
don't visit the site, and consider it "under development", i.e. unfinished.
> Yes, but back then tables were the *only* viable method of laying out your
> pages in a way that wasn't visually boring. CSS was horribly broken in
> NS4.
Netscape 4.xx _never_ supported CSS. It supported a subset of CSS
through JSSS, Javascript Style Sheets, which was a (yet another) failed
attempt at trying to support the standards before the full specification was
agreed-upon. ALL browsers tend to do this, including IE, Mozilla, Konqueror,
Opera, and others. "Selective" specification compliance is what gets them
into trouble. (IE's "box-model" flaws, Konq's lack of z-index support, etc.)
> (Actually, the Netscape4-specific JavaScript stylesheets - a variant of
> CSS - did work reasonably well.) People just had to make do with tables.
Funny, I don't recall ever having to fall back on tables just to
make my websites look non-boring. I guess each artist carries a different
paintbrush.
> It would be nice if these companies opened the source of their conduit.
> But I suspect that the conduits are specific to the needs of their company
> and are not suitable for general use.
Yes, and some are blatently violating the GPL with it too, still an
open issue with the core Plucker team, and one which should be resolved
soon.
> I believe the AvantGo servers do the page conversion and that client just
> displays the parsed HTML. (I never delved into the specifics.) Of course
> this has marketing value since it is the ultimate way of tracking usage
> and controlling content. They have to earn their money some way.
Ahem, and it has another suspiscious use as well. I tested this with
one of my pages just to try to prove a point awhileback.
I unblocked avantgo.com's netblock, sat with AvantGo's latest client
in POSE on my machine, requested my page through the "Open Page" function in
AvantGo's application, and watched the referer and useragent logs on the
server-side.
As expected, my POSE session _never_ hit the page directly. My
request was proxied through ami.avantgo.com's server, which fetched it, then
served it up to my AvantGo session in POSE. I changed the page very
slightly, but in a noticable way, and requested it again, and was served the
_same page_ as before, unmodified, without a second hit to my server from
AvantGo's domain. This indicated to me that the page was now stored on
AvantGo's servers (without my consent, mind you). If some other person were
to request the same page, it would probably have been picked up from their
cache at avnatgo.com's server farm as well, and not from my server directly.
I do not like this behavior, and I'm sure others who might be putting in
pages with authentication would like to know about this underhanded (and
undocumented) detail of the fetching process.
> In the interest of fairness you should mention that AvantGo has a
> dedicated conduit, while Plucker does not. It is still easier to use for
> ordinary users.
Dedicated conduits are a restriction, not a feature. It means you
are locked to the platform that the conduit runs on. Plucker has something
like 7 different ways to get content from web/files to your Palm device.
Applications like AvantGo, in this example, have one, and it still tethers
your Palm to the cradle until the entire content is fetched and delivered,
something Plucker does not do, thankfully.
> I don't understand how adding a back/forward/home function code will break
> functionality for other users. You're not taking away anything, you're
> adding an option. One that fits nicely with the current capabilities of
> the Viewer.
This particular addition doesn't necessarily take anything away, at
this point, but the larger issue is contining to follow in the shadows of
AvantGo's proprietary extensions to the HTML specification. I think the
goal, along with replacing simple things like this, should be to educate
content providers to fix their pages to be compliant with the HTML
specification, and other ways to increase their readership. I've had quite a
bit of good luck doing this in the past few years. Some tell me to pound
sand, and others actually work with me to clean up their pages.
d.
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
