Currently the attachments and the metadata files are stored in Namespaces/NamespaceOne/Topic/
So whatever is located in a Topic folder is related to attachments of this topic so it can't be confused with a topic wikitext file. So a namespace folder would look like this Foo.wiki Foo(2007-11-06-06-52-35.1234-candera-tear).awiki Foo\ Bar(2007-11-05-05-22-35.1234-candera-tear).awiki Bar(2007-11-06-06-52-35.1234-candera-tear).awiki Bar_0.jpg Bar_1.jpg I guess we could also use the .wiki file to improve seek time of the latest version. So it would look like Foo.wiki Foo(2007-11-06-06-52-35.1234-candera-tear).awiki Foo\ Bar.wiki Bar(2007-11-05-05-22-35.1234-candera-tear).awiki Bar(2007-11-06-06-52-35.1234-candera-tear).awiki Bar_0.jpg Bar_1.jpg Does that make sense? Let me all know what you think about this ... I'll probably get back to it this WE. Thanks; Pascal -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Andera Sent: November 6, 2007 6:57 AM To: 'FlexWiki Users Mailing List' Subject: Re: [Flexwiki-users] Topic Attachments progress report > I mean I did not implement the attachments methods for the SqlStore. > So > currently it will only work for FileSystemStore and if someone tries it > with > SqlStore it will just get to the end of the chain and throw as the next > provider will be null. > > Just to make sure this is clear. It must be implemented for SqlStore > but it is just not done yet. OK, good. Just wanted to be sure - at this point circumventing the pipeline would have all sorts of bad effects, from cache invalidation to security holes. Glad to hear you didn't do that. As for your original question about what to do with attachment version management, a couple of comments: 1) I think I like your idea about versioning the attachments separately from the metadata. I could see a reasonable story around having something that looks a lot like a topic for the metadata, but which simply points to a file that looks like Attachment_n.ext, where n is just a monotonically increasing number. 2) I'm not sure I think that using the .awiki extension for these files makes much sense. It seems to have a different meaning than the .awiki files that are already there. Maybe something like .attmeta instead. So perhaps something like this in the directory: Foo.wiki Foo(2007-11-06-06-52-35.1234-candera-tear).awiki Bar(2007-11-05-05-22-35.1234-candera-tear).attmeta Bar(2007-11-06-06-52-35.1234-candera-tear).attmeta Bar_0.jpg Bar_1.jpg Bar_2.jpg Where the Foos are regular wiki files and Bars are attachment files. This is just notional - I've probably missed an element of the filenames somewhere, but you get the idea. Another possibility is to do the attachments in a subdirectory, perhaps called "attachments". At that point you could use the .wiki and .awiki names, potentially reusing a bunch of code, and the attachments could just be called "foo.jpg" and "0-foo-jpg.archive" (or whatever). ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
