novacut-community team mailing list archive

[Jason DeRose <jderose@xxxxxxxxxxx>]

Okay, a lot of stuff here, but it took a while to digest the blur that
was UDS-N.  :)

This same stuff was also posted on the blueprint whiteboard:
https://blueprints.launchpad.net/ubuntu/+spec/multimedia-ubuntuone-n-distributed-media-library

=====

I'll try to summarize the dmedia session and the many dmedia/Novacut
discussions I had with different people at UDS.  If I've
misrepresented anyone or screwed up details, please jump in and fix
it.


dmedia + Shotwell
-----------------

    * I got the impression that Adam and Jim feel the dmedia design
overall will be easy to map into Shotwell and they seem excited about
the capabilities dmedia will bring
    * One problematic use case Jim brought up is when Shotwell
modifies the original file's EXIF data, changing the content-hash.  I
personally feel this use case is rare enough that the burden should be
on this use case rather than changing the core dmedia design.  dmedia
captures the 99% very well... pro media apps are universally
non-destructive, as are most consumer media apps these days.  Also,
dmedia provides an elegant way to have important meta-data available
everywhere, even when the media file itself isn't available locally.
Of course, when a photo is exported/rendered to share on the net or
whatever, we obviously can write whatever EXIF data needed to the
exported file... the point is just to never alter the original master
file.
    * I don't think anyone thinks we should try to replace the current
Shotwell database with dmedia in this cycle (if ever... dmedia can be
just one of several options).  Seems like the best way forward is to
integrate via a plugin, so we need to wait for the Shotwell plugin
architecture to be in place first.
    * Jim - I got the impression that you feel the plugin architecture
isn't realistic for the N cycle. Am I correct on this? How about for
the O cycle?
    * Jim and I had some great talks about standardizing the edit
description semantics... standardizing the semantics is the important
thing and something we will be working on immediately.  The exact
serialization is less important to standardize right now, but Novacut
is using a graph-based JSON description stored in CouchDB.  But if say
Shotwell uses XML (I don't know if it does, just using it as example)
that's not a problem as long as you can do a lossless round-trip
between different serialization formats.
    * Summary - there may not be any Shotwell + demdia integration
this cycle, but we will be in close communication so that we're both
moving toward a place where the integration will be easy to do when
the time comes.  Adam and Jim, you both rock! Great to meet you!


dmedia + UbuntuOne
------------------

    * All the UbuntuOne people have been very enthusiastic about
dmedia and Novacut - thanks everyone for the encouragement and
technical guidance!
    * Fortunately, for the hard dmedia problem (bi-directionally
syncing the DB), we already have full UbuntuOne integration with
basically no effort (thanks to CouchDB, desktopcouch, and the great
UbuntuOne CouchDB sync infrastructure)
    * Unfortunately, as the UbuntuOne file sync works at the directory
level, there's not an easy way to map dmedia into the UbuntuOne file
sync for cases when only an arbitrary and changing subset of the files
will be on a given device (basically determined by the access patterns
and storage capacity of a particular device... phone vs netbook vs
workstation vs storage cluster).  This is sort of the dmedia killer
feature, and in pro Video production especially, having only a partial
library on a given machine will be the rule, not the exception.  Will
also generally be the rule when in comes to video consumption.  Or
when talking phones, whether video audio or photos.
    * On the other hand, the dmedia file transport isn't a hard
problem.  We plan to make this part plugable to support multiple
backends (dmedia native, S3, removable devices, whatever).  I think
the UbuntuOne file sync works well for what it's designed to do.
Syncing read-only intrinsically named media files is quite a different
problem than bidirectionally syncing file modifications and renames on
your Documents directory.  I would personally like to see UbuntuOne
run the native dmedia storage server for dmedia use.  Stuart
Langridge... lets have a Skype chat about this.  Even if UbuntuOne
running the dmedia storage server might be a ways off, I'd like to
accommodate the UbuntuOne infrastructure design/quirks in the dmedia
storage server so that it's easy to run on UbuntuOne when the time is
right.
    * I really want to see dmedia in Natty and think it's a totally
realistic goal.  At minimum, 1) the DB must sync with UbuntuOne
(done!), and 2) some kind of file sync must be in place, even if just
over localnet and/or personal S3 account.  Ideally, file sync would be
available via UbuntuOne and there would be an app or two with dmedia
integration.
    * Summary - lets get dmedia into Natty!  What does the Novacut
team need to get done in the next 2 weeks to meet the Nov 25
Feature-Definition-Freeze criteria?
    * Special thanks to Stuart, Chad, and Manuel for fielding my many
desktopcouch questions.  All the UbuntuOne peeps rock!


dmedia + CouchOne
-----------------

    * Likewise, all the CouchOne people have been very enthusiastic
about dmedia and Novacut - thanks everyone for the encouragement and
technical guidance!
    * From talking with Jason Smith, I got the impression that
CouchOne is keenly interested in having dmedia run on phones.  This
has always been on the Novacut radar, just not the immediate radar.
But if CouchOne can aid us a bit on this front, we want to make this a
high priority (something targeted for the N cycle).
    * dmedia is simple and mostly just leverages CouchDB.  The native
dmedia file transfer will use simple HTTP.  So although the reference
dmedia implementation is being done in Python, reimplementing it in a
different language wont be much work (if I do a decent job keeping
things simple).  Plus some desktop dmedia features don't make sense on
a phone (like rendering low-rez proxy versions).  The most phone
appropriate design might work quite a bit differently too.  Like
perhaps on phones dmedia should store the media files in CouchDB
instead of on the file system using the content-hash-based layout.
    * The Novacut team doesn't have any Android/iOS development
experience, so we would need some help here.  Plus I'm personally
allergic to java and apples.  :)
    * Summary - lets get dmedia on phones!  CouchOne people, lets have
a chat soon to make sure the dmedia design decisions I'm making will
also work well on phones.  And if you already have some ideas about
how you'd implement dmedia on Android or iOS, I'd love to know what
you're thinkin'.
    * Special thanks to Jason Smith for spending like 5 hours helping
me understand CouchDB views better, best practices.  All the CouchOne
peeps rock!  Hi, Jan!


Next steps
----------

After taking a week to digest everything, I'm ready to layout the
dmedia architecture and milestones for the Natty cycle.  I'm working
on an architecture diagram that I will probably explain through, you
know, a trade mark video with pieces of paper.  Should be published in
the next few days.

Last weekend I watched college football with rockstar during which he
explained a lot of Launchpad best practices as far as making it easy
for people to understand the roadmap and take on small features.
There are just a few bugs filed so far, but many more will be filed
shortly.  I'm tagging them with 'easy':

    https://bugs.launchpad.net/dmedia/+bugs?field.tag=easy

Lastly, there is now a #novacut IRC channel where we'll idle.  We'll
also start doing a short IRC meeting once a week to keep our process
transparent and make it easy for people to join in.