Re: PlkrData Alpha Up
At 02:01 AM 11/20/2002 +, Robert O'Connor wrote: Looking through, I think it is very nicely done. Great work! Thanks. For exclusion lists, this has come up before with regards to how to package these with descriptions of sites, since that is arguably the most important part, as it is the part that most people don't know how to set up on their own. Exclusion lists are about one of the few areas of the config that would benefit from an XML format. However, XML configs isn't doable now. Also, it would be beneficial to allow the exclusions to be commandline accessbile for future tools that wanted to call the parser with specific exclusions. Therefore, it was put forward, to include exclusions as numbered keys, using the existing method of an exclusion list entry. For example: exclusion_item1=0:-:.*\.mp3$ exclusion_item2=0:-:http://.*www.x10.com/.* The parser would then loop through a section, looking to see if there was the next incremented number of key, and if so, add that exclusion to the active exclusions. This raises an issue of interfaces. Certainly we could move exclusions to Plucker.INI, but for much of my parser testing (like when I was adding --stayondomain) I ran Plucker from the command line without a corresponding INI channel. Doing that, I can load exclusion lists from the command-line. So I certainly wouldn't want to completely deprecate exclusion files. On the other hand, I also agree that all channel-specific configuration data should go in a single place, and the INI file is a good contender for that. But either way, that's not in the Parser nor would Desktop see them or save exclusions there itself, so there's not much point in doing it in PlkrData right now. The exclusion list has GOT to wind up in a file on the other side. So packaging it as an encoded blob is probably faster than enumerating through a series of keys. Okay, I've got two minds about this. If you would like to coordinate work on this with me, I can handle the parser and PlkrData side with you handling the Desktop side of putting these changes into a synchronized release. I'm thinking that compatibility with the installed base would be a "good thing" though. -Tony McNamara- ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: PlkrData Alpha Up
On 19 Nov 2002 at 11:29, Fringe Ryder wrote: > Since I haven't gotten any more feedback, I finished up icon functionality > my way and have tossed her up on the web. > > http://kittycentral.net/Plucker/PlkrData.html > > Both sources and a Windows binary are there. > > All the basics work - registration under Windows (not Linux yet), saving, > and loading channel data and icons. > > Still to-do are things that we didn't think of in the discussions - > packaging up exclusion lists and unregistering - plus the Linux > registration. Cross-process communications with Desktop may have to wait, > since I can't find any sign that Desktop would be expecting a message sent yet. > > Feedback would be very appreciated. Looking through, I think it is very nicely done. Great work! For exclusion lists, this has come up before with regards to how to package these with descriptions of sites, since that is arguably the most important part, as it is the part that most people don't know how to set up on their own. Exclusion lists are about one of the few areas of the config that would benefit from an XML format. However, XML configs isn't doable now. Also, it would be beneficial to allow the exclusions to be commandline accessbile for future tools that wanted to call the parser with specific exclusions. Therefore, it was put forward, to include exclusions as numbered keys, using the existing method of an exclusion list entry. For example: exclusion_item1=0:-:.*\.mp3$ exclusion_item2=0:-:http://.*www.x10.com/.* The parser would then loop through a section, looking to see if there was the next incremented number of key, and if so, add that exclusion to the active exclusions. Best wishes, Robert ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Non-HTML (was Re: Back/foward/home function code)
> > Yes! We want in Plucker now! > I enjoyed the Python comment next to the 'blink' on the list of currently > unimplemented tags in the Parser (TextParser.py, around line 855). Props > to whoever wrote that in. Appears to be Ondrej back in Parser.py, almost to the day 11/22/99. For those that don't remember him, Ondrej Palkovsky[1] and Holger Duerer wrote the first Python iterations back in 1999 that replaced the awk/perl code we were using, and it was the first to use "disconnected" fetching mode. Previously, you had to cradle your Palm, and a single .pdb was created at sync time on your Palm, one... record... at... a... time. [1] http://www.penguin.cz/~ondrap/ d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Non-HTML (was Re: Back/foward/home function code)
On 20 Nov 2002 at 0:55, MJ Ray wrote: > Robert O'Connor <[EMAIL PROTECTED]> wrote: > > -Others: maybe the "marquee" tag from MSIE 3.x days, and all the other non- > > standard crap that has come and gone over the years. > > Yes! We want in Plucker now! I enjoyed the Python comment next to the 'blink' on the list of currently unimplemented tags in the Parser (TextParser.py, around line 855). Props to whoever wrote that in. > Seriously, has anyone who asks for support for standards-breaking actually > thought the effect of it through to a conclusion? I think Plucker should be > praised for taking a reasonably pure-standards approach on this. It's the > only way that you can hope to keep things sane *and* moving forwards. I agree 100%. I am amazed that any web designer which has struggled with the pain of having to deal with the woes of proprietary browser tags in years gone by, and is now working on Plucker with a bona- fide chance to shape their own future of their distribution medium tools, would opt for pollution of them by standards-breaking non-HTML. Best wishes, Robert ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Non-HTML (was Re: Back/foward/home function code)
Robert O'Connor <[EMAIL PROTECTED]> wrote: > -Others: maybe the "marquee" tag from MSIE 3.x days, and all the other non- > standard crap that has come and gone over the years. Yes! We want in Plucker now! Seriously, has anyone who asks for support for standards-breaking actually thought the effect of it through to a conclusion? I think Plucker should be praised for taking a reasonably pure-standards approach on this. It's the only way that you can hope to keep things sane *and* moving forwards. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
At 12:17 AM 11/20/2002 +, MJ Ray wrote: Fringe Ryder <[EMAIL PROTECTED]> wrote: > I find a mailing list nearly ideal. The only detriments to it are that the= > odd message is flagged as spam by my filters and I haven't determined why,= You need to add the lists to your whitelist or scorefile. That's why I'm confused. I did. All of rubberchicken is whitelisted. But since it only rarely happens and never when I'm not in a hurry (darned "critical detectors"!), I haven't tracked it down. Probably something simply like a residual spam filter somewhere else. > and that threads I care nothing about still show in my in box. You need to improve your mail filters. No, I mean threads from Plucker-General or Plucker-Dev about things like top-posting. Certainly we could solve world hunger and eliminate all war by reducing top posting, but how much, deep down, should I really care? HTH, HAND. ;-) HTH? Oddly, all that line puts into my head is "Millenium hand-and-shrimp, buggerit!" -Tony McNamara- ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Non-HTML (was Re: Back/foward/home function code)
At 11:54 PM 11/19/2002 +, Robert O'Connor wrote: On 19 Nov 2002 at 15:22, Fringe Ryder wrote: > At 10:53 PM 11/19/2002 +, Robert O'Connor wrote: > >On 18 Nov 2002 at 21:43, Laurens M. Fridael wrote: > > > complying with W3C standards is hardly a priority or > > > even a consideration. > > > >I would tend to differ on that point. > > > >Over the next few years, Plucker is going to become the dominant force as > >it continues to > >mature and the commercial alternatives wither. AvantGo, in particular is > >on the downgrade, with > >a delisted stock, layoffs, CEO resignations, and sagging sales. > > > >As Plucker continues to rise, I would offer that Plucker chooses the best > >practices, in the > >form of documented W3C and ISO standards, instead of picking up the bad > >practices of the > >withering commercial off-line browsers. > > Hmm... what about those of us who want the tool to work in as many cases as > easily-possible, rather than being holier-than-thou and refusing to work on > sites because they have innocuously-broken code? > > (This doesn't refer to the "back" functionality; I don't care about > that. I use Plucker for content, not for buttons. It just refers to the > board-mentality that Plucker should be less tolerant of errors than any > browser, instead actively refusing to touch sites with even the most minor > of transgressions.) *I* am not going to: (a) work on crap non-standard proprietary non-HTML. (b) offer support on mailing lists on how to use crap non-standard proprietary non-HTML. (c) maintain the extra work to maintain compatibility of crap non-standard proprietary non-HTML, as they change underfoot since they aren't standard. (d) document them all and how to make them work. (e) maintain the docs. Robert, I'm not clear that you've done any parser work anyhow; I don't expect you to work on it. You did the Desktop, which is also extremely important and impressive, and very content-agnostic. But do you notice any prejudicial tone in your message? "crap non-standard proprietary non-HTML" Nobody asked for support of that specifically. Sure, some "non-standard" HTML, depending on whose standard (W3 or the real world/market.) Sure, some crappy HTML that would have been standard if not for the fact that a color (to use your example) wound up not in the standard or a tag got misused in a common fashion. Certainly not any "non-HTML", unless you define "non-HTML" the way David does, as disqualifying a document that has a single malformed comment tag, for example. I have made several parser changes recently, and would consider doing some to expand Plucker's usefulness should a common not-quite-standard usage be interfering broadly with usage. Things that are perhaps supported by all four major browsers we might want to consider. Purity that substantially reduces functionality is useless. Which is nice, but currently (for me) academic. No such features are annoying me. I never noticed the example you used, the non-implemented color code, perhaps due to a certain level of color blindness. I don't use "back" buttons; the browser's history is good enough for me since it DOES take me back where I came from. And I have scripting (and cookies generally) disabled in my browser (Opera), so I don't tend to see sites that require them and would fail in Plucker. But the philosophy remains none-the-less: I want Plucker to be useful more than I want it to be an arrogantly useless tribute to a standards body. On the bright side, right now it's both a tribute to a standards body AND useful, at least to me. But if we should have to pick a direction in the future, I vote "useful." And, as long as nobody screams too loudly, I'll code it too. -Tony McNamara- ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
Fringe Ryder <[EMAIL PROTECTED]> wrote: > I find a mailing list nearly ideal. The only detriments to it are that the= > odd message is flagged as spam by my filters and I haven't determined why,= You need to add the lists to your whitelist or scorefile. > and that threads I care nothing about still show in my in box. You need to improve your mail filters. HTH, HAND. ;-) -- MJR| v ---|--[ Something else will appear here eventually, I guess... ]-| `--[ http://mjr.towers.org.uk/ ]-[ slef at jabber.at ]-' ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
Blake Winton <[EMAIL PROTECTED]> wrote: > Not all of the "advantages". If I subscribed to the lists today > as a new subscriber, I couldn't reply to any message before today. Yes, you can. The archive site allows you to download a mailbox with all messages to date in it, which you can then read and reply to like any other emails you get. It's one link to save. Not much trouble if you want it. [...] > I like the mailing lists, myself. My only request would be to expose > a news interface as well, so that Google Groups could index the list. I have software which does this. A couple of scripts added on to the sn small newsserver. This message comes to you via it. -- MJR| v ---|--[ Something else will appear here eventually, I guess... ]-| `--[ http://mjr.towers.org.uk/ ]-[ slef at jabber.at ]-' ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
At 10:53 PM 11/19/2002 +, Robert O'Connor wrote: On 18 Nov 2002 at 21:43, Laurens M. Fridael wrote: > complying with W3C standards is hardly a priority or > even a consideration. I would tend to differ on that point. Over the next few years, Plucker is going to become the dominant force as it continues to mature and the commercial alternatives wither. AvantGo, in particular is on the downgrade, with a delisted stock, layoffs, CEO resignations, and sagging sales. As Plucker continues to rise, I would offer that Plucker chooses the best practices, in the form of documented W3C and ISO standards, instead of picking up the bad practices of the withering commercial off-line browsers. Hmm... what about those of us who want the tool to work in as many cases as easily-possible, rather than being holier-than-thou and refusing to work on sites because they have innocuously-broken code? (This doesn't refer to the "back" functionality; I don't care about that. I use Plucker for content, not for buttons. It just refers to the board-mentality that Plucker should be less tolerant of errors than any browser, instead actively refusing to touch sites with even the most minor of transgressions.) -Tony McNamara- ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: VFS Best Practice
On 25 Oct 2002 at 10:35, Wayne A. Arthurton wrote: > What are people doing to install your Plucker DBs to a memory card w/o > having to manually change the location on each one? > > I'm considering making all my DBs start with pkr e.g. pkrSlashDot and > then have in script run a move all DBs that start with pkr from the > Install dir to the Memory Stik install dir in the Palm Desktop. There is support deduced for SD-Cards. What is the mechanism for Memory Stick, and can possibly support that also. -Do the files go to a specific Memory Stik dir on the harddrive to be transferred to device? -Is it enough just to put them in the dir, and they get installed, or is there other items to be done also, like flicking a memory switch? Best wishes, Robert ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
Robert O'Connor wrote: > On 18 Nov 2002 at 21:43, Laurens M. Fridael wrote: > >> complying with W3C standards is hardly a priority or >> even a consideration. > > I would tend to differ on that point. You're quoting out of context! I already had a lengthy discussion with David about this. I'm not going to explain my point of view again. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
On 19 Nov 2002 at 11:12, David A. Desrosiers wrote: > Ugh, the worst of the offenders. There are no forms on the Onion's > website, yet they still need to rely on this pods://avantgo/back syntax? > Useless. On that page, _ALL_ articles reference index.html, and to all > articles, index.html is their parent. The << "The Onion" link that brings > you back could just as easily been a link to index.html, just like the > _millions_ of other fully functional websites around the world do it. I > guess this is the AvantGo'ish hack for history.back() in Javascript, and on > this site, is a completely moot example, since it doesn't actually explain > the use of it any further. I agree 100%. The only possible reason that I can see for it, is that it is one less link to queue, because it isn't a true hyperlink, it is an embedded command. I don't know how it is in AvantGo, since I haven't used it in about a year, but in Plucker, many of the sites require breadth first, and breadth first maintains a queue of all links until the end until it sees if it has already been retrieved. So in the onion case: -With regular links to index.html: 10 extra links are queued and get time is spent checking, and seeing that it already been downloaded. -With "back" commands: no extra links queued, no memory required to store this link until the end. It is bit dubious though as far as whether functionality goes though. Best wishes, Robert ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
On 18 Nov 2002 at 21:43, Laurens M. Fridael wrote: > complying with W3C standards is hardly a priority or > even a consideration. I would tend to differ on that point. Over the next few years, Plucker is going to become the dominant force as it continues to mature and the commercial alternatives wither. AvantGo, in particular is on the downgrade, with a delisted stock, layoffs, CEO resignations, and sagging sales. As Plucker continues to rise, I would offer that Plucker chooses the best practices, in the form of documented W3C and ISO standards, instead of picking up the bad practices of the withering commercial off-line browsers. Best wishes, Robert ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
At 10:37 PM 11/19/2002 +0100, Michael Nordström wrote: On Tue, Nov 19, 2002, TIM CONSTANTINE wrote: > It seems to me that a Bulletin Board for communication would have > some serious advantages over this mailing list: As have already been pointed out the "advantages" are already available for the mailing list. If you started to use a differet system for communication then I can point out one major disadvantage: - some core developers will be missing Now, some of you might think it is an advantage that I'm not there to complain about lousy mail etiquette, but in the long run you will still lose if core developers don't take part in the discussions. On the contrary, I've been worried sick about you because you haven't been griping about all the top-posters recently. I've been re-arranging quotes in messages I respond to, such that oldest are on top, but the prevalence of what used to be effective bait for you from newer posters, with nary a response, has me concerned about your well-being and vigor. I'm not even sure you've blacklisted anyone, as you promised in http://lists.rubberchicken.org/pipermail/plucker-list/2002-October/000483.html ! (I'm less worried about David because while he too has been quiet on the mail-formatting front, he still pipes up regularly about "standards", somehow presuming that we only care about Plucking content that fully meets the documented standards. I listen to people with less-than-perfect English, I have a less-than-perfect wife, and I enjoy or learn from less-than-perfectly-implemented web sites. Good thing I have the association with the fully-perfect David to help bring the average up! ) I'm delighted that you are apparently in full health. BTW, I find it a bit amusing that newcomers always are so quick to suggest that we should abandon the mailing list. Do you really think we would continue to use a mailing list if we didn't think it was a good way to communciate? ;-) I find a mailing list nearly ideal. The only detriments to it are that the odd message is flagged as spam by my filters and I haven't determined why, and that threads I care nothing about still show in my in box. But these are very minor inconveniences relative to having to perform some web action to view activity. I'm not, despite my web sites, career, and plucker involvement, likely to hit a web site with regularlity. I sometimes only hit /. once a day! -Tony McNamara- ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
RE: Bulletin Board instead of Mailing List?
> On Tue, Nov 19, 2002, TIM CONSTANTINE wrote: > > It seems to me that a Bulletin Board for communication would have > > some serious advantages over this mailing list: > As have already been pointed out the "advantages" are already > available for the mailing list. Not all of the "advantages". If I subscribed to the lists today as a new subscriber, I couldn't reply to any message before today. This is what TIM meant by "jumping into conversations". I guess I could, if there was a publicized way to, ask the list server to forward me a specific message from some time in the past. Then I could browse through the archives, and collect messages to respond to, ask the server for them, and reply, but that seems like a bit more trouble than new users would be willing to go through. > If you started to use a differet system for communication then I > can point out one major disadvantage: > - some core developers will be missing Unless, as David suggested, the board and the lists are kept in sync. Of course, that would mean only plain-text messages on the board (or have the syncing software run each message through lynx before forwarding it on), but I guess that's a fairly small price to pay. > BTW, I find it a bit amusing that newcomers always are so quick to > suggest that we should abandon the mailing list. Do you really think > we would continue to use a mailing list if we didn't think it was a > good way to communciate? ;-) I like the mailing lists, myself. My only request would be to expose a news interface as well, so that Google Groups could index the list. The palm-dev-forum already does this, and I find it quite useful. (I like Google's search engine better than pretty much every other one I've found so far.) > Also, since I have all the message locally I can search in every mail > sent to our mailing lists since '98 without going online and > I wouldn't want to lose that possibility. If it was mirrored, you wouldn't. Later, Blake. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
On Tue, Nov 19, 2002, TIM CONSTANTINE wrote: > It seems to me that a Bulletin Board for communication would have > some serious advantages over this mailing list: As have already been pointed out the "advantages" are already available for the mailing list. If you started to use a differet system for communication then I can point out one major disadvantage: - some core developers will be missing Now, some of you might think it is an advantage that I'm not there to complain about lousy mail etiquette, but in the long run you will still lose if core developers don't take part in the discussions. BTW, I find it a bit amusing that newcomers always are so quick to suggest that we should abandon the mailing list. Do you really think we would continue to use a mailing list if we didn't think it was a good way to communciate? ;-) Also, since I have all the message locally I can search in every mail sent to our mailing lists since '98 without going online and I wouldn't want to lose that possibility. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
I agree. >>> [EMAIL PROTECTED] 11/19/02 04:15PM >>> > Yes, I know different mailing lists could be created, but the whole > Plucker system needs to work together, and you may need to "jump into and > out of" different conversations to do what it is that you want to do. As long as it works directly with the mailing lists, and does not obsolete them, I'm all for it. Whatever goes into the forum should appear on the lists, and vice versa, so there is no loss of context, or at least it should be exposed in a return from a search engine which can consolidate both. Remember, the purpose of all of this is to _prevent_ fracturing, and asking people to use the lists, forum, faq, search engine, etc. where all of them work independantly of each other may cause a larger fracture than intended. d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
> Yes, I know different mailing lists could be created, but the whole > Plucker system needs to work together, and you may need to "jump into and > out of" different conversations to do what it is that you want to do. As long as it works directly with the mailing lists, and does not obsolete them, I'm all for it. Whatever goes into the forum should appear on the lists, and vice versa, so there is no loss of context, or at least it should be exposed in a return from a search engine which can consolidate both. Remember, the purpose of all of this is to _prevent_ fracturing, and asking people to use the lists, forum, faq, search engine, etc. where all of them work independantly of each other may cause a larger fracture than intended. d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: PlkrData Alpha Up
Oh, OK... Thanks... Looking forward to it... >>> [EMAIL PROTECTED] 11/19/02 03:45PM >>> At 03:35 PM 11/19/2002 -0500, TIM CONSTANTINE wrote: >I understand that, but if Plucker Desktop is invoking PlkrData, then it >knows that something has changed and can just set ITSELF up. > >I guess what I'm calling for is for whoever is working on Plucker Desktop >(sorry, I don't know who's who yet) to work with you to add your >functionality to that program. It seems to me, that would provide the >most intuitive user experience. Oh, THAT's the angle you're missing. I expect PlkrData would be called by Plucker Desktop to EXPORT channels, but that usually the user's web browser will IMPORT them. For example, you might browse the list of sites on Wiki and click on the ones you want added; the .plkrdata file downloads and "runs", invoking PlkrData, and they get installed to your channel list in Plucker.ini. In these cases, if the user is surfing the web when they already have Plucker Desktop up, they'd have to exit and restart Desktop to see the new channels. Desktop doesn't know that anything just happened. Robert is the Desktop guru, but I've helped out recently on it a bit, mostly just bug clean-up. We (he and I) have already discussed switching Desktop from it's "Showcase" area to using PlkrData internally. I even choose the libraries I used to be most Desktop-compatible. So it will probably come, but probably not this week. -Tony McNamara- ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
> It seems to me that a Bulletin Board for communication would have some > serious advantages over this mailing list: We've talked about this before. I've been wanting to create a nice search engine for the list(s) and FAQ and docs, and I have something very similar working on pilot-link.org's site now, but the problem with the current scheme, is that the mail for Plucker is in several places.. once that gets consolidated, it will be much easier to mangle around a search engine. > - It would be searchable Planned. (the ones at mail-archive.com already are) > - It would be easier to jump into & out of conversations Based on searching? Should be possible.. > - It would be easier to locate previous threads of discussion (history) > phpBB would be good. The problem with a "forum" style interface, is that it gets really hard to follow the lists (which many of us prefer), then jump to a web browser to follow off-list threads, then jump into the bugtracker to reference bugs that are discussed on both lists and forum. It gets to spread us out too thin, and that can fracture the discussions more than adding a forum will purport to help. > Can this be added to plkr.org? Yes, some of us are a bit buried in other work, currently though, and adding a forum at this point (for me at least) has slipped down the list a bit. Finding gainful (i.e. paying) employment is at the top of my list, and I'm also scaling up with a bunch of new servers to increase the capacity we're about to see when I launch my.plkr.org and some other tools I've been working on in the background. > If not, I can put one up, but if I build it, will you come? If you'd like, hit me privately, let's work on it. I can farm out some tasks to you if you'd like to help. I have some things that are fairly straightforward to do, but just take some time to do, and time isn't something I have lots of spare of lately. d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
It's threaded & searchable like a BB, but I don't have the ability to jump into and out of conversations. Also there's one "dev" list - with a BB, multiple categories can be created according to different developers tastes & aspirations (i.e. one for Plucker Desktop, one for Plucker Viewer, etc.). Yes, I know different mailing lists could be created, but the whole Plucker system needs to work together, and you may need to "jump into and out of" different conversations to do what it is that you want to do. In general a BB is more user friendly than a Mailing List. Where I say "user", you can read "novice" if you'd like, but if you really want "a helping hand maturing Plucker into a more useful and popular project," I think a BB would be better. >>> [EMAIL PROTECTED] 11/19/02 03:49PM >>> At 03:21 PM 11/19/2002 -0500, TIM CONSTANTINE wrote: >It seems to me that a Bulletin Board for communication would have some >serious advantages over this mailing list: > >- It would be searchable >- It would be easier to jump into & out of conversations >- It would be easier to locate previous threads of discussion (history) > >phpBB would be good. > >Can this be added to plkr.org? > >If not, I can put one up, but if I build it, will you come? It's already in BBS form. General http://lists.rubberchicken.org/pipermail/plucker-list/ Dev http://lists.rubberchicken.org/pipermail/plucker-dev/ Don't do this by memory... I tried, went to www.rubberchicken.org, and found an extremist political site instead. You want lists.rubberchicken.org. -Tony McNamara- ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
At 03:21 PM 11/19/2002 -0500, TIM CONSTANTINE wrote: It seems to me that a Bulletin Board for communication would have some serious advantages over this mailing list: - It would be searchable - It would be easier to jump into & out of conversations - It would be easier to locate previous threads of discussion (history) phpBB would be good. Can this be added to plkr.org? If not, I can put one up, but if I build it, will you come? It's already in BBS form. General http://lists.rubberchicken.org/pipermail/plucker-list/ Dev http://lists.rubberchicken.org/pipermail/plucker-dev/ Don't do this by memory... I tried, went to www.rubberchicken.org, and found an extremist political site instead. You want lists.rubberchicken.org. -Tony McNamara- ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: PlkrData Alpha Up
At 03:35 PM 11/19/2002 -0500, TIM CONSTANTINE wrote: I understand that, but if Plucker Desktop is invoking PlkrData, then it knows that something has changed and can just set ITSELF up. I guess what I'm calling for is for whoever is working on Plucker Desktop (sorry, I don't know who's who yet) to work with you to add your functionality to that program. It seems to me, that would provide the most intuitive user experience. Oh, THAT's the angle you're missing. I expect PlkrData would be called by Plucker Desktop to EXPORT channels, but that usually the user's web browser will IMPORT them. For example, you might browse the list of sites on Wiki and click on the ones you want added; the .plkrdata file downloads and "runs", invoking PlkrData, and they get installed to your channel list in Plucker.ini. In these cases, if the user is surfing the web when they already have Plucker Desktop up, they'd have to exit and restart Desktop to see the new channels. Desktop doesn't know that anything just happened. Robert is the Desktop guru, but I've helped out recently on it a bit, mostly just bug clean-up. We (he and I) have already discussed switching Desktop from it's "Showcase" area to using PlkrData internally. I even choose the libraries I used to be most Desktop-compatible. So it will probably come, but probably not this week. -Tony McNamara- ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
>What about writing a Plucker authoring guide, with guidelines specifying >which parts of HTML are supported, how to achieve particular formatting, >what to do and what not to do, etc.? Or is there such a thing already? >I'm planning to write a reference for JPluck that explain how HTML is >parsed, including a tag-by-tag reference. The Python distiller may do >things differently, but there definitely is common ground. This reference can >become an authoring guide over time. I'm willing to pick up this task. I think this is a great idea. I'd be willing to help out. I've been meaning to write a guide for Pluckerbooks (with an ebooks slant of course) for some time, but it would be nice to have an 'official' plucker guide. Dave. [EMAIL PROTECTED] ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: PlkrData Alpha Up
I understand that, but if Plucker Desktop is invoking PlkrData, then it knows that something has changed and can just set ITSELF up. I guess what I'm calling for is for whoever is working on Plucker Desktop (sorry, I don't know who's who yet) to work with you to add your functionality to that program. It seems to me, that would provide the most intuitive user experience. - Tim >>> [EMAIL PROTECTED] 11/19/02 03:26PM >>> > >>> [EMAIL PROTECTED] 11/19/02 02:29PM >>> >Since I haven't gotten any more feedback, I finished up icon functionality >my way and have tossed her up on the web. > > http://kittycentral.net/Plucker/PlkrData.html > >Feedback would be very appreciated. > > -Tony McNamara At 03:09 PM 11/19/2002 -0500, TIM CONSTANTINE wrote: >Great work Tony. This will be very handy. > >Just one comment - it seems to me that Plucker Desktop should be the one >communicating with PlkrData, not the other way around. That is, you >should be able to use the Plucker Desktop GUI to import/export channels (& >behind the scenes, Plucker Desktop could use PlkrData to do just that). > >Am I missing something? Thanks. Yes, just one thing... If PlkrData installs a new channel while Plucker Desktop is already running, the less savvy users will wonder why the new channel doesn't appear in Desktop. The reason is that Desktop reads the INI once excepting certain heavy operations; it doesn't expect the INI to suddenly change. So the intra-process communications would be to reduce user annoyance. -Tony McNamara- ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: PlkrData Alpha Up
>>> [EMAIL PROTECTED] 11/19/02 02:29PM >>> Since I haven't gotten any more feedback, I finished up icon functionality my way and have tossed her up on the web. http://kittycentral.net/Plucker/PlkrData.html Feedback would be very appreciated. -Tony McNamara At 03:09 PM 11/19/2002 -0500, TIM CONSTANTINE wrote: Great work Tony. This will be very handy. Just one comment - it seems to me that Plucker Desktop should be the one communicating with PlkrData, not the other way around. That is, you should be able to use the Plucker Desktop GUI to import/export channels (& behind the scenes, Plucker Desktop could use PlkrData to do just that). Am I missing something? Thanks. Yes, just one thing... If PlkrData installs a new channel while Plucker Desktop is already running, the less savvy users will wonder why the new channel doesn't appear in Desktop. The reason is that Desktop reads the INI once excepting certain heavy operations; it doesn't expect the INI to suddenly change. So the intra-process communications would be to reduce user annoyance. -Tony McNamara- ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Bulletin Board instead of Mailing List?
It seems to me that a Bulletin Board for communication would have some serious advantages over this mailing list: - It would be searchable - It would be easier to jump into & out of conversations - It would be easier to locate previous threads of discussion (history) phpBB would be good. Can this be added to plkr.org? If not, I can put one up, but if I build it, will you come? ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: PlkrData Alpha Up
Great work Tony. This will be very handy. Just one comment - it seems to me that Plucker Desktop should be the one communicating with PlkrData, not the other way around. That is, you should be able to use the Plucker Desktop GUI to import/export channels (& behind the scenes, Plucker Desktop could use PlkrData to do just that). Am I missing something? - Tim >>> [EMAIL PROTECTED] 11/19/02 02:29PM >>> Since I haven't gotten any more feedback, I finished up icon functionality my way and have tossed her up on the web. http://kittycentral.net/Plucker/PlkrData.html Both sources and a Windows binary are there. All the basics work - registration under Windows (not Linux yet), saving, and loading channel data and icons. Still to-do are things that we didn't think of in the discussions - packaging up exclusion lists and unregistering - plus the Linux registration. Cross-process communications with Desktop may have to wait, since I can't find any sign that Desktop would be expecting a message sent yet. Feedback would be very appreciated. -Tony McNamara ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
Laurens M. Fridael <[EMAIL PROTECTED]> wrote: >> it seems that SVG may not be in a happy place for free software >> either, because of patents held on some of its core methods. > Akin to the LZW patent used by GIF? I'll take a look. Actually, I think they're far more pervasive than that. With the GIF patent, there was only one and a better format that avoided the patent was possible anyway. >> Please, get your hands dirty and start work if you're convinced >> people will want this. It may well be the case that you have to >> maintain a "PluckNGo" branch so as not to load the main code with a >> lot of unnecessary baggage, but it should be doable. > Right now, JPluck takes up all my programming time and there's still a lot > to cover there. Maybe later. Indeed, I understand that, but I don't think any of the current core have the right time+willing available to do this for you now, so pleading will have little effect. Maybe it will encourage someone new to start contributing to plucker? Failing that, it will just have to wait. MJR ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
PlkrData Alpha Up
Since I haven't gotten any more feedback, I finished up icon functionality my way and have tossed her up on the web. http://kittycentral.net/Plucker/PlkrData.html Both sources and a Windows binary are there. All the basics work - registration under Windows (not Linux yet), saving, and loading channel data and icons. Still to-do are things that we didn't think of in the discussions - packaging up exclusion lists and unregistering - plus the Linux registration. Cross-process communications with Desktop may have to wait, since I can't find any sign that Desktop would be expecting a message sent yet. Feedback would be very appreciated. -Tony McNamara ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
Wesley Mason wrote: > Ok... > > Can we, for argument sake, in the parser have it translate the > pods://avantgo/back link to a link to the prior page? > > I think this solves alot of the problems. I totally agree. This is the best solution for now. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
David A. Desrosiers wrote: >> No, you don't understand, I'm talking about the link *back* from C >> to A or B. Look at the The Onion for example. >> http://mobile.thenion.com/ > ^o > > Ugh, the worst of the offenders. There are no forms on the Onion's > website, yet they still need to rely on this pods://avantgo/back > syntax? Useless. On that page, _ALL_ articles reference index.html, > and to all articles, index.html is their parent. The << "The Onion" > link that brings you back could just as easily been a link to > index.html, just like the _millions_ of other fully functional > websites around the world do it. I guess this is the AvantGo'ish hack > for history.back() in Javascript, and on this site, is a completely > moot example, since it doesn't actually explain the use of it any > further. I mentioned The Onion to illustrate that HTML in the real world is sloppy. Sure, they should get their act together. Again, I'm not saying the "back" usage is right, I'm saying it happens. I have to dig up a better example. >> If you have a link labeled "back" then the user expects to go back. >> Granted, there is a case for not labeling your links "back" since the >> whole concept of 'going back' is difficult to uphold on the web. > > Yep, there is no "up", "back", "deep", "lower" etc. on the web. > Everything is exactly one link from everything else. The web is flat, > horizontal. Traversing "up" or "down" a website or "directory" > structure is just a human misnomer to help understand how the web > works, but is incorrect.. Not necessarily. "back" and "forward", "up", "down" should be seen as metaphors. Most people think of web browsing as "going" from one place to another, as in "visiting a site". In fact, humans use a lot spatial metaphors in their language and conceptual system. (Source: "Metaphors We Live By", a well-known book on the subject by George Lakoff and Mark Johnson.) Is this off-topic or what? ;-) > I've yet to see it, and see in such a way that uses approved > standards (i.e. not using Javascript, Flash, ActiveX, etc.). Got a > link? The HTML DOM is a W3C standard, and JavaScript is an official standard as well(ECMAScript). I'll dig up a good example. > Then use connection-based forms, or NPH to do that work. Perhaps > XForms is what you really desire: http://www.w3.org/MarkUp/Forms/ XForms is not yet supported by the major browsers, is it? It's still a candidate recommendation. Sure, there's always the latest and greatest most standardized approach, but if you need results now you can't always have it your way. If you really want the cleanest approach then the browsers should support XSLT so we can just the deliver XML and the stylesheets and truly have a clean separation between content and presentation. However, even if they did, older browsers would continue to be used and would still have to be supported. You can't just dismiss an audience, because this or that standard is now approved by W3C. People may be using PCs that won't even run the latest Mozilla, IE, or Opera. It's just unrealistic to expect 100% compliance with standards from every client that connects. Standards are good, and necessary. We agree on that. The reality is that the popularity of the web has grown at too high a rate for standards committees to keep up. The "browser war" is also to blame. >> Of course, forms should be clear and well-designed. But users still >> make all kinds of mistakes. They might accidently press enter in a >> text field, thus triggering a form submission. > > Then disable that feature. Enter in a form field doesn't always have > to translate to Enter on a Submit button. Poorly designed forms will > do this, however. The user might expect that pressing the enter key will submit the form, since that's how it works by default in the major browsers. Interfering with this is not a good idea from a usability standpoint. (Ironically, disabling the enter key behavior requires a JavaScript hack.) >> I'm not sure I follow. You can never be sure of the record ID in a >> back link unless there is only one link to the text record. > > Parent. You consolidate the links to the parent by the number of > times the children reference it. This happens all the time in > spiders, and I'm sure I could dig up quite a few thesus papers on the > web describing it. Sorry, I still don't follow. You can determine the record id of the back link only if one page references the target. So if you have A->C B->C and want to have a back link in page C, then there's no way of figuring *at document creation time* which link, A or B, that should be. > Ugh, it uses Flash and requires Javascript to process it. No thanks Well it was an example of Flash usage, and not of HTML. The bad thing is that they have no alternative for Flash whatsoever. Still the Flash usage is very nice. > The client only sees Nike, Coca-Cola, etc. and says "I want that". > They don't ca
Re: Back/foward/home function code
Ok... Can we, for argument sake, in the parser have it translate the pods://avantgo/back link to a link to the prior page? I think this solves alot of the problems. --Wes - Original Message - From: "David A. Desrosiers" <[EMAIL PROTECTED]> To: "Plucker Development List" <[EMAIL PROTECTED]> Sent: Tuesday, November 19, 2002 11:12 AM Subject: Re: Back/foward/home function code > > > No, you don't understand, I'm talking about the link *back* from C to A or > > B. Look at the The Onion for example. http://mobile.thenion.com/ > ^o > > Ugh, the worst of the offenders. There are no forms on the Onion's > website, yet they still need to rely on this pods://avantgo/back syntax? > Useless. On that page, _ALL_ articles reference index.html, and to all > articles, index.html is their parent. The << "The Onion" link that brings > you back could just as easily been a link to index.html, just like the > _millions_ of other fully functional websites around the world do it. I > guess this is the AvantGo'ish hack for history.back() in Javascript, and on > this site, is a completely moot example, since it doesn't actually explain > the use of it any further. > > > If you have a link labeled "back" then the user expects to go back. > > Granted, there is a case for not labeling your links "back" since the > > whole concept of 'going back' is difficult to uphold on the web. > > Yep, there is no "up", "back", "deep", "lower" etc. on the web. > Everything is exactly one link from everything else. The web is flat, > horizontal. Traversing "up" or "down" a website or "directory" structure is > just a human misnomer to help understand how the web works, but is > incorrect.. > > > The server validation is of course what the application should rely on, > > but there is a place for basic client-side validation as well. > > I've yet to see it, and see in such a way that uses approved > standards (i.e. not using Javascript, Flash, ActiveX, etc.). Got a link? > > > For instance, if I forget to fill in a required field I'd rather have some > > alert notifying me that I forgot that field rather than click, wait, and > > then find out to my annoyance that I still need to fill it in. > > Then use connection-based forms, or NPH to do that work. Perhaps > XForms is what you really desire: http://www.w3.org/MarkUp/Forms/ > > > Of course, forms should be clear and well-designed. But users still make > > all kinds of mistakes. They might accidently press enter in a text field, > > thus triggering a form submission. > > Then disable that feature. Enter in a form field doesn't always have > to translate to Enter on a Submit button. Poorly designed forms will do > this, however. > > > I'm not sure I follow. You can never be sure of the record ID in a back > > link unless there is only one link to the text record. > > Parent. You consolidate the links to the parent by the number of > times the children reference it. This happens all the time in spiders, and > I'm sure I could dig up quite a few thesus papers on the web describing it. > > > One example is http://www.mycom.nl/ It's a Dutch site, though. I really > > like the way they've done it. The interface is snappy and responsive. I > > find this a good example of delivering actual usage with Flash, rather > > than just providing fancy animations or games. > > Ugh, it uses Flash and requires Javascript to process it. No thanks > (and didn't properly load when both were enabled in my browser anyway). > Popup windows that remove the titlebar, removing navigation elements, all > major faux pas when designing HTML pages. Accessibility is apparently not > one of their concerns, and I'm sure they only care about their IE users > anyway, so I wish them luck. Oh, also, their error page has 404's on it (how > ironic), and a broken image. Someone should buy them a "Learn HTML in 12 > Hours" book or something. > > > I agree that there should be fallback behavior. A site should not > > absolutely rely on its popup menus, etc. But time is money, and designers > > won't always be able to provide alternatives for every browser. The client > > wants a fancy site, just like Nike, Coca-cola, etc. > > The client only sees Nike, Coca-Cola, etc. and says "I want that". > They don't care how it works, they want it to look like that. I understand > that, and I've worked under those constraints before, but believe me, when > you show the client other alternatives, specifically one which will ensure > that their userbase will _increase_ because the site will look good in _all_ > of their user's browsers, they are much more enthused, and it takes less > time to design a compatible site, than it does to design an incompatible > one. > > > Netscape did support standard CSS. You can link CSS stylesheets using > > and some of it works. Netscape DevEdge at least claimed NS4 > > supported CSS. Sure, CSS in NS4 is *virtually* unusable. > > It supported a limit
VFS Best Practice
What are people doing to install your Plucker DBs to a memory card w/o having to manually change the location on each one? I'm considering making all my DBs start with pkr e.g. pkrSlashDot and then have in script run a move all DBs that start with pkr from the Install dir to the Memory Stik install dir in the Palm Desktop. But that seems a little ugly. W ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
> No, you don't understand, I'm talking about the link *back* from C to A or > B. Look at the The Onion for example. http://mobile.thenion.com/ ^o Ugh, the worst of the offenders. There are no forms on the Onion's website, yet they still need to rely on this pods://avantgo/back syntax? Useless. On that page, _ALL_ articles reference index.html, and to all articles, index.html is their parent. The << "The Onion" link that brings you back could just as easily been a link to index.html, just like the _millions_ of other fully functional websites around the world do it. I guess this is the AvantGo'ish hack for history.back() in Javascript, and on this site, is a completely moot example, since it doesn't actually explain the use of it any further. > If you have a link labeled "back" then the user expects to go back. > Granted, there is a case for not labeling your links "back" since the > whole concept of 'going back' is difficult to uphold on the web. Yep, there is no "up", "back", "deep", "lower" etc. on the web. Everything is exactly one link from everything else. The web is flat, horizontal. Traversing "up" or "down" a website or "directory" structure is just a human misnomer to help understand how the web works, but is incorrect.. > The server validation is of course what the application should rely on, > but there is a place for basic client-side validation as well. I've yet to see it, and see in such a way that uses approved standards (i.e. not using Javascript, Flash, ActiveX, etc.). Got a link? > For instance, if I forget to fill in a required field I'd rather have some > alert notifying me that I forgot that field rather than click, wait, and > then find out to my annoyance that I still need to fill it in. Then use connection-based forms, or NPH to do that work. Perhaps XForms is what you really desire: http://www.w3.org/MarkUp/Forms/ > Of course, forms should be clear and well-designed. But users still make > all kinds of mistakes. They might accidently press enter in a text field, > thus triggering a form submission. Then disable that feature. Enter in a form field doesn't always have to translate to Enter on a Submit button. Poorly designed forms will do this, however. > I'm not sure I follow. You can never be sure of the record ID in a back > link unless there is only one link to the text record. Parent. You consolidate the links to the parent by the number of times the children reference it. This happens all the time in spiders, and I'm sure I could dig up quite a few thesus papers on the web describing it. > One example is http://www.mycom.nl/ It's a Dutch site, though. I really > like the way they've done it. The interface is snappy and responsive. I > find this a good example of delivering actual usage with Flash, rather > than just providing fancy animations or games. Ugh, it uses Flash and requires Javascript to process it. No thanks (and didn't properly load when both were enabled in my browser anyway). Popup windows that remove the titlebar, removing navigation elements, all major faux pas when designing HTML pages. Accessibility is apparently not one of their concerns, and I'm sure they only care about their IE users anyway, so I wish them luck. Oh, also, their error page has 404's on it (how ironic), and a broken image. Someone should buy them a "Learn HTML in 12 Hours" book or something. > I agree that there should be fallback behavior. A site should not > absolutely rely on its popup menus, etc. But time is money, and designers > won't always be able to provide alternatives for every browser. The client > wants a fancy site, just like Nike, Coca-cola, etc. The client only sees Nike, Coca-Cola, etc. and says "I want that". They don't care how it works, they want it to look like that. I understand that, and I've worked under those constraints before, but believe me, when you show the client other alternatives, specifically one which will ensure that their userbase will _increase_ because the site will look good in _all_ of their user's browsers, they are much more enthused, and it takes less time to design a compatible site, than it does to design an incompatible one. > Netscape did support standard CSS. You can link CSS stylesheets using > and some of it works. Netscape DevEdge at least claimed NS4 > supported CSS. Sure, CSS in NS4 is *virtually* unusable. It supported a limited subset of CSS, through the JSSS engine. > To each their own. I still like to a see a good sidebar done without > tables and without any CSS. Maybe a trick with or transparent > GIFs? ;-) Nope, not at all. Sidebars are easy with CSS, including spacing, etc. that will look like a transparent gif if you wish. Here's one quick example I just googled for: http://www.meyerweb.com/eric/css/ > AvantGo obviously favors its registered content providers. An
Win32 Plucker Conduit.
> > What do you mean by a "dedicated conduit"? Plucker has had > > a (Win32) conduit for quite a while now. > Where? Right! That was harder to find than I would have hoped. (Google gave me nothing for "Plucker conduit", so I had to go back through my saved email from the list to find it.) It's called PlkrCond, and can be found at: http://plkrcond.extrareto.de/ Later, Blake. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
Blake Winton wrote: > What do you mean by a "dedicated conduit"? Plucker has had > a (Win32) conduit for quite a while now. Where? Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
David A. Desrosiers wrote: >> 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. No, you don't understand, I'm talking about the link *back* from C to A or B. Look at the The Onion for example. http://mobile.thenion.com/ If you have a link labeled "back" then the user expects to go back. Granted, there is a case for not labeling your links "back" since the whole concept of 'going back' is difficult to uphold on the web. If you visit a random page in a site, for instance, arriving via a search engine, then a link labeled "back" makes no sense at all. But these links do occur. Sloppy as they may be. > 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 I'll take a look at that. > ..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. Client-side form validation is only a bonus. Rather than requiring a roundtrip to the server, which is definitely an issue on a slow connection, you can do basic form validation on the client. (Some web application frameworks take care of this automatically. They generate the form including JS validation code for the client.) The server validation is of course what the application should rely on, but there is a place for basic client-side validation as well. For instance, if I forget to fill in a required field I'd rather have some alert notifying me that I forgot that field rather than click, wait, and then find out to my annoyance that I still need to fill it in. Of course, forms should be clear and well-designed. But users still make all kinds of mistakes. They might accidently press enter in a text field, thus triggering a form submission. > 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). I'm not sure I follow. You can never be sure of the record ID in a back link unless there is only one link to the text record. >> 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 Flash does have a lot going for it for the end-user. For a start it is a small download, even for modem users. Second, you can do things that ordinary HTML just cannot do(or not well). I've seen online stores that are fully Flash-based and communicate to the server back-end using XML. One example is http://www.mycom.nl/ It's a Dutch site, though. I really like the way they've done it. The interface is snappy and responsive. I find this a good example of delivering actual usage with Flash, rather than just providing fancy animations or games. > 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. I agree that there should be fallback behavior. A site should not absolutely rely on its popup menus, etc. But time is money, and designers won't always be able to provide alternatives for every browser. The client wants a fancy site, just like Nike, Coca-cola, etc. >> 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 Netscape did support standard CSS. You can link CSS stylesheets using and some of it works. Netscape DevEdge at least claimed NS4 supported CSS. Sure, CSS in NS4 is *virtually* unusable. >> (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 f
Re: Back/foward/home function code
MJ Ray wrote: > There's a conversation just started on [EMAIL PROTECTED] and > it seems that SVG may not be in a happy place for free software > either, because of patents held on some of its core methods. Akin to the LZW patent used by GIF? I'll take a look. > Please, get your hands dirty and start work if you're convinced > people will want this. It may well be the case that you have to > maintain a "PluckNGo" branch so as not to load the main code with a > lot of unnecessary baggage, but it should be doable. Right now, JPluck takes up all my programming time and there's still a lot to cover there. Maybe later. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
RE: Back/foward/home function code
> > 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) > 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. Okay, I've got two pages, A, and B. Both have a link to C. I want to put a "Back" link on C. Which page does it point to? > > 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. I used to use client-side form validation _all_ the time. Not as a replacement for server-side validation, but as a way to short-cut most of the errors the client might get, since it's a lot faster than having to make yet another connection to the server to find out what's wrong. > 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. Oooh! This sounds like a teaser for some good news. I can't wait. > > 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. What do you mean by a "dedicated conduit"? Plucker has had a (Win32) conduit for quite a while now. > it still tethers your Palm to the cradle until the entire > content is fetched and delivered, something Plucker does > not do, thankfully. And that's why I uninstalled the Plucker conduit a week after installing it. :) > 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. I think that the goal should be to produce a browser that handles as many things as it can without becoming too slow. (I've found that asking people to fix their pages has been almost as useful as pounding sand, and so would rather have a client that's liberal in what it accepts, and does its best to render whatever crap it's given.) Of course, this is the beauty of Open Source. People can submit patches to drive the product in the direction they want it to go. Later, Blake. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
Laurens M. Fridael <[EMAIL PROTECTED]> wrote: > [...] The Adobe SVG plug-in, for instance, is still way too heavy compared > to Flash and there aren't enough good SVG authoring tools for designers, > nothing that can compare with Flash MX, that is. [...] There's a conversation just started on [EMAIL PROTECTED] and it seems that SVG may not be in a happy place for free software either, because of patents held on some of its core methods. [...] > It may not be your goal, but people see Plucker as an AvantGo replacement. > And if you go the extra mile in supporting some of AvantGo's features that > are relatively easy to implement in the Viewer - like the back function - > you will ease over the transition. [...] Please, get your hands dirty and start work if you're convinced people will want this. It may well be the case that you have to maintain a "PluckNGo" branch so as not to load the main code with a lot of unnecessary baggage, but it should be doable. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Avantgo vs Plucker vs Zaurus
Just FYI, I've put a modified version of the Avantgo vs Plucker table on my website with an extra column added for Opie-Reader (the Zaurus/Opie on ipaq reader). It should give people a better idea of where I've got to with it - see http://www.timwentford.uklinux.net/a-vs-p.html I did it mostly as an education for myself (what am I missing*) but I thought others might be interested. *Table support, sub/superscripts, scaling of images, mailto tags. OTOH there is support for other etext formats, external dictionaries, continuous mode and font zooming - I don't know if these exist on the Palm reader and were omitted from the table as not worthy of mention so I draw no conclusions 8^). BTW, don't worry to much about errors etc as it is not linked to from anywhere and the only place I've published the URL is here - plus I'll be removing it fairly soon anyway.. Cheers Tim ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
> 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 con
Re: Back/foward/home function code
David A. Desrosiers wrote: > [page a] -follows link to-> [page b] > > [link on page b called "Back" ] > 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. I believe this is actually what the AvantGo people had in mind with the pods:// syntax. > And thankfully, we can disable that garbage. If you mean Javascript, > look closely at the recent statistics, a large(r) percentage of > people keep Javascript and Java disabled (along with other "active" > scripting technologies) because of the whole host of problems > associated with using it, and the fact that 90% or more of people who > use it, have no idea what they're doing, and end up deploying buggy > code. I agree that JavaScript is abused in the most horrible ways(the dreaded pop-up comes to mind). I run Proxomitron to get rid of the worst behavior, but I don't have JavaScript fully disabled. However, some functionality, like client-side form validation, is nice to have, though. > Should we support Java and Flash too, because those are used as > well? 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. >> Just look at the popularity of Flash. Flash is a proprietary >> technology. > > No, _Macromedia_ Flash is a proprietary technology, the .swf format > that drives it is not, and you can find all about it at: While it's not proprietary, Macromedia does control the SWF format. And they make sure that Flash MX offers the latest and greatest implementation for authoring SWF content. FMX is a big money-spinner for Macromedia. They have no interest in supporting open standards like SVG. >> I'd rather see an open W3C standard like SVG dominate, but that's not >> going to happen considering Flash's current market share. > > Market share doesn't dictate standards, contrary to popular media > opinion. Standards exist for a reason, and like it or not, they work. Agreed, but it isn't helping SVG. The Adobe SVG plug-in, for instance, is still way too heavy compared to Flash and there aren't enough good SVG authoring tools for designers, nothing that can compare with Flash MX, that is. Complicated as FMX may be, designers do produce some nice content with it once in a while. >> To be fair, nowadays the browser situation is much better. When I >> did web development (1997-2001) you still had to struggle with >> making your pages work with table-based layouts in both Netscape4 >> and IE4/5. > > ..probably because tables aren't designed to be used for "layout". 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. (Actually, the Netscape4-specific JavaScript stylesheets - a variant of CSS - did work reasonably well.) People just had to make do with tables. > I can't stand seeing web "developers" use 1-pixel transparent gifs > all over the place, in nested tables, just to try to position their > images on the page. Yes, I was guilty of things like that in my past > too, and I learned how to do it right, and I won't ever make those > mistakes again going forward. Yes, but you're not taking into account the importance of corporate image to some people. Your clients will push you to make the page look exactly like their paper brochure. They don't care about the transparent gifs or web-unsafe colors, they only care about what they actually see on their screen. They'll tell you that the Nike or Coca-Cola site does it this or that way, or that Levi's has this cool animation, whatever. To some people image is everything. But we're talking about the past. Back then you had to resort to these hacks. The situation is much better now. > I notified my bank of their "error" in this decision, including > copying them in on several _dozen_ incidents where IE was the direct > cause to people being taken advantage of and robbed through their > online transactions being "peeked" through IE's vulnerabilities. They > soon changed tact, and now accept other browsers. This is a good example of why standards are important, so that people have a choice. >> (Besides, Netscape4 has a very bad reputation among developers. In >> fact, some developers charged double when the goal was to make the >> page work in both IE and Netscape4.) > > Sigh. Once again, amateur developers probably did tend to do this, > and I'm sorry it ruined it for the rest of us professional developers. I can assure you that these developers were *not* amateurs. Rather, they were experienced developers, fully aware of the many hoops you had to jump through in order to make the page look the way the client wanted(with Netscape4 being so terribly bro
