Hi Evan, Thanks for getting back to me. Sorry I misread the specifications and thought it meant you wanted the user to be able to use their SN account to upload to their Flickr profile - not that you wanted to create an API to allow people to access stored photo's in a similar way to Flickr. But that's fine, I think I could do that too.
Regarding the multiple uploads, I saw there was a bit of debate about this. The reason I went about adding it was because it was mentioned as something wanted on the wiki under the Photosharing API heading. I understand the points you raise but isn't it possible that the user would like to upload two very similar photos, which would use the same tags etc? Or if someone's designing something, makes 3 mockups and wants feedback as to which is the best one - wouldn't that be more complicated if they had to post 3 times? Maybe I could add an option to allow the site admin to decide whether to allow multiple uploads? Finally, is it possible to specify in the proposal that I would do the Photosharing API as the primary task, with the addition then of working on the rich text editing if I get the Photosharing one done to a good standard? Thanks, Nick Holliday On Mon, Mar 29, 2010 at 2:43 AM, Evan Prodromou <[email protected]> wrote: > Nicholas Holliday wrote: > > 1) Create the Flickr API as described on the wiki. > > Note that the project is not just to clone the Flickr API. It's to create a > "lite" photo-sharing service, like Flickr's. Supporting the Flickr API is > probably the best way to get third-party apps to support the system, but > it's not the whole project. > > I have already completed a lot of the groundwork including the multiple > uploads feature and getting photo's to be uploaded to Flickr. > > Well, great to hear that you're getting acquainted with the code! I'm > concerned about design decisions, though. > > Keeping one photo per notice means that the notice can serve as the > description of the photo; the metadata on the notice (like location and > #hashtags) can be metadata for the photo; replies to the notice can serve as > comments on the photo; and that feeds and such all come out correctly. If > you do multiple attachments per notice, then you have to start having ways > to ascribe metadata to the attachments. That's way harder! > > I would add functionality to allow adjusting photos (I envisage using > similar, if not the same, code to that of the editing of avatars when they > are uploaded.) > > Fine, but do it last. > > I also thought it would be nice if, once an image (or I suppose any file) > is selected, it is uploaded automatically in the background. > > Fine, fine. > > This information would then be sent along with the image to Flickr to be > stored. > > Wait, what? Photos should be stored with the StatusNet server, not at > Flickr. I think you might have got your head around the "Flickr Lite" name > too much. > > I realise that taking on two of the proposals could be seen as > over-optimistic however in the time I've been playing around with the > StatusNet code I've learnt a great deal about how it works and am confident > I would be able to complete both projects to a good standard in the time > allowed. > > It makes more sense to do one project well. If you get really jammed up, > we'll have you work on a pluggable backend for storing media. B-) > > -Evan > > -- > Evan Prodromou > CEO, StatusNet, [email protected] - http://evan.status.net/ - > +1-438-380-4801 > >
_______________________________________________ StatusNet-dev mailing list [email protected] http://lists.status.net/mailman/listinfo/statusnet-dev
