> 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.
I think you misunderstood my explanation, so let me try to come up
with a better analogy.
When you tune in with a television, you have a guide, a schedule
that tells you which shows are playing, and when. These shows have been
"prepared" for you, sprinkled with commercials, to fit within a given
timeslot. You sit and watch from the beginning of that timeslot to the end,
and you get the "programming schedule" for the night. At no point were you
involved in the creation of this programming schedule. It was prepared for
you beforehand. It came from one central source, and was guaranteed to fit
within the timeslot allowed, and was guaranteed to be broadcasted and
available from that channel.
AvantGo, by example, uses this same mentality. They aggregate their
collections of content on a schedule, store them on the AvantGo servers.
This content is prepared *FOR* AvantGo by the content providers, formatted
for the Palm, tweaked, optimized, and customized for that screen and viewing
area. When you connect via AvantGo, either wireless or serially, you are
being delivered the "programming schedule" for your Palm, based on what you
decided to "tune into".
Plucker, in contrast, is 100% user driven *CONTENT*, vs. user-driven
*PROGRAMMING*. The difference here is that the content may break, be too
large for them, of the wrong type, badly written, may not be available, or
access to it may be denied. It is certainly not "prepared" for them
beforehand (think content, not parser, that's a different beast).
The difference with a channel vs. a Plucker "stream|pluck|document"
is that a channel is a known entity, controlled, customized beforehand,
knowing the end-user device, credentials, and so on. Within the Plucker
design, it is completely 100% unknown, can change, may break,
I'm not 100% opposed to any name: channel, pluck, document,
zorgoblif or whatever. I'm simply saying that we may end up confusing the
users into believing that there's some central repository where this content
can be obtained from, some sort of "content aggregation service", which
implies a channel, which implies some sort of subscription. Sure they can
download an XML file which described their content. I can easily see the "I
subscribed with the XML file, but the content doesn't appear when I hit
sync" type of problems.
> Document isn't bad, connotation is somewhat static though.
We've misused it before, and I'm sort of opposed to propagating the
term, since there are something like 23+ doc readers now. At some point, it
may come that Plucker, via a plugin, supports reading DOC files directly,
which then means Plucker content (created *BY* plucker) and Documents (*NOT*
create by Plucker) may be available within the Plucker UI. If we globally
use the term "Document" now, that's going to get much more confusing later
on if that feature is added.
> 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.
An easy-to-explain analogy:
pluck == fetch
How do you describe a channel in one word?
> 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's a restriction on the number of users allowed to use that
prepared content on the provider's site. Take a peek at this message:
http://plkr.org/list/plucker-list/0567.html
Specifically:
"[anon] for instance, www.pocketpcthoughts.com
are now shutting down their official
AvantGo channel because they're being
charged with $6000 USD since they have
more than 5000 registered AvantGo
subscribers"
The content providers are, by contract, told to restrict the access
to the content with any measures that will only allow the content to be
retrieved by AvantGo's browser, and also restrict access to any means of
getting access to that same content. As an example, in my local database
here, I have:
mysql> select rowid, url from pods where url like '%avantgo%' order by url;
201 rows in set (0.01 sec)
That means that specifically, 201 of those URLs which I have access
to, should be restricted by their contractual agreement with AvantGo. The
remaining 337 that do not have AvantGo in their URI are free to do what they
want, officially, I believe. Yes, not all of them have to have the string
'avantgo' in their URI, but this is a loose guage.
> 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.
I rather like a way to subscribe to a list of available streams
online, if only for the purposes of building you a custom script which can
be downloaded and run locally, prepared for your customizations. The server
holds the urls, and when you configure each of the ones you want, you are
delivered one large XML file which is used by $TOOL to download them. When
you want to change those things, you can either log in (XML file stored by
account name) or upload your existing locally stored XML file and have the
server "figure out" who you are and adjust the settings accordingly.
Just some ideas. I am all in favor of a client-side operation as
well, and it's still one of the reasons I use Plucker every single day.
/d
