John
fascinated by the RSS enclosure functionality.

Is this widely available - now? and if so do you know if Movable
Type has the capability.

many thanks
Wayne

--- In klogs@yahoogroups.com, John Robb <jrobb@o...> wrote:
> Dear K-Loggers,
>
> A defining aspect of a K-Log network is that it is an extremely
effective
> one-to-many publishing system. What makes a K-Log network
effective (as opposed
> to communications systems like e-mail, phone, and IM) is its
passivity. What do
> I mean? People aren't forced to read what's published. Readers
only visit or
> subscribe to a K-Log when they have a need to do so or if they
deem what the
> author says is important. This passivity allows readers to batch
process their
> reading and be selective about who they read. This optimization
saves time.
>
> This feature makes K-Logs a great distribution system for files
(like
> multimedia and office documents). Increasingly, employees are
using easy-to-use tools to create
> audio and video files of meetings, events, interviews, and more.
They already
> produce loads of documents that are often quite large.
>
> So, how should people distribute this content? One way is through
e-mail
> attachments. However, this method has two major drawbacks. First,
it bogs down
> e-mail servers. Given that most people keep a significant portion
of their
> e-mail on a server, an e-mail with a 2 Mb attachment sent to 300
other employees
> produces 600 Mb of bloat in the e-mail database. That's not a good
thing and it
> drives sys-admins nuts given the limitations on e-mail databases.
Also, it
> forces people to download it whether they are interested in it or
not. This is
> particularly bad over a slow connection when on the road.
>
> A second way is to just post it to a file folder on a file server.
The problem
> with this is that it strands the file, without sufficient context.
This context
> is necessary. It provides people with a reason to download the
file.
> Additionally, given the status of most files systems I have ever
seen, it will
> likely be lost forever in a jumble of shared files. A third way is
to use
> shared workspaces (collaboration tools). Unfortunately, while
these systems may
> provide a small modicum of improvement in delivering crucial
contextual data,
> they share the same limitations of communications tools like e-
mail: they work
> best within the context of small groups and not very well in a one-
many
> environment.
>
> In my view, the best way to distribute a large file is to publish
it via a K-Log
> to the Intranet. Here's why:
>
> 1) Sharing. Using this method people reading a K-Log can find out
how file
> relates to the author's worklife; before they download it. For
example, "Here
> is a video of a example sales presentation for product xxx," or "I
just revised
> my marketing presentation for product yyy. It includes some new
graphs on
> performance of the system that the product team thinks are
necessary to explain
> to customers." This relevant information saves time, effort, and
limits
> confusion. It makes effective sharing possible.
>
> 2) Trust: K-Logs introduce a large measure of trust into the act
of
> distributing files. The file is attached to an identifiable person
within the
> organization. Additionally, there is little threat of virus laden
files on a
> K-Log relative to e-mail. The very nature of K-Logs contains virus
propagation.
>
> 3) Archives. With K-Logs, Intranet's become an archive of what
goes on within a
> company. In regards to file storage, K-Logs provide the archival
data
> necessary to understanding why the was created, when it was
created, why it
> should be used, where it should be used, and much more. Intranet
search
> functionality is also improved because the value of the file is
enhanced by the
> number of K-Logs pointing to it (particularly when Google's
appliance is used).
>
> 4) Economics. Since only the people that want to download the file
download it.
> Additionally, forwarding large files within a K-Log context
becomes a snap.
> All I need to do to forward a file is to either post a link to my
K-Log for my
> readers to use or send the link via e-mail directly to people that
could benefit
> from it. Very simple and lightweight. There is very little wasted
bandwidth,
> storage, or server utilization.
>
> Another aspect of a K-Log network that is starting to gain
traction is distributing
> files as part of an RSS subscription (Disney is using this
technique to distribute
> large files to 2 m users). K-Logs automatically publish
syndicatable
> content in the form of RSS (a standard syndication format). That
means if I am
> using an RSS aggregator tool on my desktop, I can subscribe to the
K-Logs I find
> interesting and get all the new posts automatically without having
to visit the
> sites. Further, all of these subscriptions are aggregated on a
single "news"
> page for easy scanning. Most people use this functionality to keep
track of an
> order of magnitude more sites than they can through simple
bookmark-enabled
> browsing.
>
> What isn't well known is that it is possible to include a large
file as an
> enclosure with an RSS feed. That means that subscribers can
automatically get
> all files I publish, delivered to their desktop, without having to
go through
> the process of active downloading. Enclosure downloading can also
be time
> shifted to occur only during the wee hours of the night to prevent
congestion
> problems (this can be done by simply typing in the time you want
things to be
> downloaded). This also means that when a reader clicks on a large
file that has
> been distributed as an enclosure, it launches immediately. There
isn't any
> world-wide-wait.
>
> There has also been some good work integrating P2P (a clean
corporate version of Napster
> and KaZaA) into RSS enclosure distribution. This would make
distribution even
> less expensive to do.
>
> In conclusion, if you are a company that deals with lots of
multimedia files and
> multiple revisions of documents, K-Logs should be a simple
solution to many of
> your woes.
>
> Sincerely,
>
> John Robb
>
> http://jrobb.userland.com
>
>
>
> [Non-text portions of this message have been removed]