[bookport] Re: The inevitability of Podcasting

  • From: "LARRY SKUTCHAN" <lskutchan@xxxxxxx>
  • To: <bookport@xxxxxxxxxxxxx>
  • Date: Tue, 03 May 2005 08:40:54 -0400

Don:

I agree, we are just starting to see the phenomenon, and you are right,
it is going to get big.

So far, I really love the technique of using an external card reader
and extra flash card then telling the software to use the folder on the
flash card to hold all the downloads.  Then, when you finish with one,
you just delete it.  

There are a couple of things that make this a little less than
perfect.

1. Book Port needs a way to remove a folder once it is empty and
perhaps even when it is not.  The software I have used creates a new
folder to hold individual casts, and having it create a new folder is a
good way to see what is new.

2. This does require an extra card and a drive, but this is a good
thing in some ways, because you may continue to use the device while
casts get downloaded.

3. Book Port needs a way to list the newest material on the device.

What could be simpler and more convenient for the user?

>>> Don.Barrett@xxxxxx Tuesday, May 03, 2005 3:02:11 AM >>>
All,
I think the practice of PodCasting will become so popular that APH will
have to sooner or later grapple with not if, but how the bp will deal
with this phenomenon.  

Probably the biggest issue will be the necessity when sending podcasts
to the bookport, of how the transfer software will be able to discern
which casts were already sent and which ones are new. The transfer
software will have to know which podcasts have been sent and which ones
have not, in the same way that the podcasting software knows which casts
have been downloaded and which ones have not.

Perhaps the transfer software might keep an internal log of all
podcasts sent to the bookport so that if someone let's say once a week
simply says send all podcasts, only the new ones are sent.
In this way, even if a person deletes old casts from the bookport or
the pc, the log will ensure that only new casts are sent without the
user having to figure out manually which ones have been sent or not.
If I have 20 casts on my bookport and read 10 of them and delete those
10 from the bookport, I won't want the same ones sent again even though
they are no longer on the bookport.  An internal log could handle all of
this.
Even if I delete a bunch of casts from the pc, this shouldn't confuse
the transfer software as it is using its complete internal log to
compare against sends.

Don





Other related posts: