> > All the other GUI subscribed portable Palm web systems I have ever seen > > use the term channel, probably for easier first user/migration, and the > > fact that new people are familiar with the concept of a 'channel' > > The only one I know of that does this is AvantGo. > > Sitescooper uses "scoops" or "nightly scoops", for example. I'm not > aware of any others that actually ACTIVELY pull content from > sites and parse > it for a digestable view on the Palm.
The other 2 that I am thinking of specifically are ISiloWeb (which was reborn as ISiloX) [ www.isilo.com ], and Pendragon's offering www.pendragon-software.com/browser ]. Both of these (and AvantGo) use the term 'channel' to describe their things, rather than calling it an 'isilo' or a 'pendragon'. I certainly am not a lawyer, but I don't think there can possibly be a trademark on the term 'channel'. SiteScooper isn't reknowned for being the easiest of the cabal to be used. > With Plucker, the user initiates a script/gui/whatever, which goes > out on the LIVE internet, gathers content from live sites, which > may be up, > down, or slow, and then parses it locally, which creates a file > they have to > sync to their Palm. There is certainly a different achitecture, in an AvantGo push vs. Plucker pull model. From the casual user point of view though, the results on the Palm look indistinguishable. > Calling what we do a "channel" is misleading in this aspect. > Channels in the vein of telecommunications or television, > indicates that you > have something "canned" for your viewing pleasure (or displeasure > of late), > which has been audited/edited to suit your medium. This doesn't > apply in our > case, for a majority (most) of our users who use Plucker. I disagree with you on this. This is exactly what Plucker is doing, and what is supposed to be doing. I tell it the source of the information, then it is auditing out the javascript, the HTML comments, and the other crap I don't want, and formatting it to suit my medium which is a Palm pilot with a small screen and low processing power. > > --Document: (ties with viewer's Document manager well). > > Documements can be stored in Plucker, so this fits well.. Document isn't bad, connotation is somewhat static though. > Here we > introduce the nature of "plucks" (suggested by another user, just today > online. I think I've tossed the term around before also) I think "Pluck" isn't bad either, and the word can be extended into whatever meaning desired. The drawback is that mmediately people don't know what one is talking about. It reminds me of "Flooz". One has to always define and remind what one is talking about. One also makes the user feel stupid by giving them terms they don't understand. Here is a snippet from the lists "This Program" thread from this past August. While most casual users aren't going to be so vehement, I think their confusion will be the same: "All I wanted was to get a program that takes files from off the web and transfer it into my handheld. But this program is not simple. Not everyone can use it. Even the instructions are hard because half the terms I have no idea what they mean." Whether the tradeoff is worthwhile is something to decide upon. > > --Database: the former name of Library manager. > > Content is stored in a database or databases. This also fits, but > one does not make a channel of "databases", however one can have "database > of channels". One can also pluck content into a database. I would recommend against using a term with database, since while to developers the .pdb is technically a database format, calling it a database leads it into being something like a JFile or HanDBase columned and rowed data, instead of some information content. This is probably why the extra work was put in by Michael to change DBManager to 'Library' to make it more descriptive. Of the options other than database, I will abstain from voting. MJ weighs in on 'Pluckable (site)' or second choice of 'Plucker Document'. Will work on aspects of the code and leave this until later so have one that people are happy with, sound reasonable? > if only "familiar" to those people with televisions > (luckily I > am not one of them =) I tossed out my television in 1996 (have to pay a TV Tax in Ireland to have one, so has to be good stuff on for me to keep it). I will watch the Simpsons reruns in the retirement home though, some new ones to look forard too--though dementia by then make make them all seem like new episodes to me, whether I've seen them or not. :) > It's also important to note that AvantGo *RESTRICTS* content from > users and content providers. It does not in any way open it up at > all. I've > had some pretty lengthy discussions with a lot of AvantGo content > providers, > and all of them agree that they're put under extremely tight restrictive > agreements from AvantGo, and that heavy fines ensue of they > violate any part > of that agreement. It's expensive to become an "authorized" > AvantGo content > provider, and really, for no reason. A question on this: I believe the license is just a restricted directory, not a restriction of exclusive providership to handhelds, is this the case? Does the content provider just have to have a separate contentprovider.com/avantgo directory and a contentprovider.com/handheld directory to get their info on all the handhelds? > It would not be that hard to create a server and subscription-style > service to create "Daily Plucks" or something like that. The only > limitations are 1.) bandwidth, 2.) permission from content providers, 3.) > storage size and probably some other minor issues. > > The question for the class though is, do we want a Plucker Server, > filled with user-submitted content and populated with the 600 or so > Palm-formatted URLs I have in my PODS system here? Or do we want > to leave it > all client side still? I am quite happy myself with a full-client side solution. That certainly shouldn't exclude other mechanisms which would be useful for others, similar to the way we have parsers for python, but also different languages. Best wishes, Robert
