[Podserver-devel] RE: Podserver

[Tom K. <te...@ya...>]

Cool.

I wish I had thought about this sooner, but we should probably continue this
on the mailing list, so that others in the project can see what we've been
chewing over.

-----Original Message-----
From: Foster, Richard - PAL [mailto:RF...@qu...] 
Sent: Friday, January 06, 2006 3:34 PM
To: Tom Kent
Subject: RE: Podserver

Hi again Tom,

Probably the best thing to do is just keep checking what we do against
reality and make sure we don't let them get too far apart! It certainly
seems like your initial model is a good one, but the only way anyone
really finds out for certain that their schema is good is when they use
it! :-)

Yes, there is going to be a lot of binary data. Like I said, storing it
directly in the database may not cause problems (especially not in a
non-Microsoft world). The other option would be to store it as simple
files. They may need to be renamed (since different people may want to
upload files with the same filename), but that could be a simpler
option. Yes, there is still potential for corruption, but my (admittedly
limited) experience is that anything bad only happens to one set of
binary data, rather than many. The bad thing about storing the binary
data "by reference" in this manner is that it is much more difficult to
do a complete backup.

It sounds like we're on the same page as far as limiting the RSS feed is
concerned. The archive could then be presented as a set of dynamically
generated pages, using CSS to apply appropriate publication-specific
"branding".

Regards,
Richard

P.S. How did I hear about this project? Simple, by listening to Fr
Roderick and being a member of the SQPN team (I'm rjfoster over there!)
:-)

-----Original Message-----
From: Tom Kent [mailto:te...@ya...] 
Sent: Friday, January 06, 2006 16:16
To: Foster, Richard - PAL
Subject: RE: Podserver

Yeah, I does sound like you have more experience than me.  I'd be more
than open to any criticisms/revisions/completely new models that you may
have :-)

I was also planning MySQL for at least the first stage.  I think that it
will be easiest on everyone.  Once there's free time, we could add
functionality for other DBs.

I didn't realize storing binary data this way would cause problems.
Could it be alleviated with using an MD5 sum and checking periodically
or something of that nature?  How would you recommend we store the
binary data....there's going to be A LOT of it.

I was thinking that limiting the RSS feeds to N number of episodes would
probably be the best way to go.  Then we could have another (non-rss?)
page that would list the archived versions.  We could also put in the
ability to delete an episode if there's something that people want to
get rid of (like someone included copyrighted material that they got
busted for).  I don't want to make deleting stuff a typical occurrence
though.

I don't think things in the version control world will get too
complicated early on.  Hopefully converting to SVN when it comes down
will be painless.

Tom

P.S.  Where did you hear about this project?  Did you just surf to it?