[PP-main] working towards peer press 1.0

[lists at itsg.net.au]

well, i'd like to see the ability for affiliate sites to choose
whether or not to download the binary data after previewing it's
description.

ok - work with me here 8^)
when the affiliate site posts the data onto the pp network, here's what
it might look like:

<ppdata>
 <author>
  <firstname>Fred</firstname>
  <lastname>Smith</lastname>
  <email>fred.smith at example.net</email>
  <phone>+61-7-55000000</phone>
 </author>
 <content>
  <synopsis>this is an interview with the development team of
peerpress.org</synopsis>
  <type>audio/mp3</type>
  <size>4500000</size>
  <data>BINARY CONTENTS OF THE FILE WOULD GO HERE</data>
 </content>
</ppdata>

when the affiliate sites receive the description of the file,
it would be the above minus the <data></data> and the contents
in between. they can then poll the server for the content if they
want it.

there are advantages and disadvantages to doing it this way.
the main advantage i think would be that you don't have to worry
about sites moving the content around - instead, pp carries the content
on its servers. the disadvantages are then of course bandwidth usage
and storage.

also, if the content (ie photo) is referenced from inside a text document
(ie article), there should be some kind of option in the protocol to
automatically receive the binary data.

am i way off course here?

- avi

On Mon, 13 Mar 2000, Nick Lothian wrote:

> [snip]
> > does everyone think that the system would be better if *any* sort of
> > binary data were simply described in XML and then the affiliate sites
> > decide on a case by case basis of what data types they will receive?
> >
> 
> Yes, this is what I was saying. It brings up another point, though - should
> the syndicate XML file
> contain the file being syndicated, or should it point to it?
> 
> For example, it is pretty simple for an XML file to contain a plain text
> story (or one with tags for formatting). However, for other rich media types
> (MPEG files for instance), the affiliate sites would probably want the file
> and the description separate, so they can download the description, and then
> decide if they want to get the actual content.
> 
> Perhaps we should have both: the file can contain <CONTENT> or it can
> contain a <CONTENT-URL> pointer to the resource.
> 
> This brings up the problem of older material - if the original site
> publishes using <CONTENT-URL>, and then moves (or deletes) the file what
> happens then?
> 
> Also, if you are publishing a GIF file, for instance, how do we stop people
> displaying the picture on their site without copying it (ie, using the
> picture hosted on your site, with all the bandwidth problems that causes).
> Should we worry about this? Sites can use the HTTP-REFERER thing to block
> direct access - but that is a little messy. Some sites might actully want
> you to use the one on their site, so they can track interest in that item or
> something.
> 
> Nick
> 
> 
> 
>