Brilliant! I'm going to use this as my development guide from here. Thanks.
Vince On May 14, 3:44 pm, Baz <[email protected]> wrote: > Being able to port apps without any changes to them is an extremely valuable > proposition. Instant, hassle-free load-balanced and redundant application > delivery with no work on my part? Sign me up! But of course, as Vince > mentioned, there are challenges to this. So lets first assume that we > definitely wanted to make this happen, what would we need? Well, put simply, > we would need to treat the 2 file-systems as 1: > > *UPLOADING/WRITING > *Of course, all uploads and writes would happen on the virtual filesystem*. > > NAME CONFLICTS > *Since this behaves like 1 filesystem, name conflicts need to be handled > properly. If nameconflict=makeunique, then we have no problem, we just > create a new file with a new name in the virtual filesystem if it exists in > EITHER filesystem. Now what if nameconflict=overwrite? In that case, we > simply upload the file to the virtual filesystem (either create it new or > overwrite an existing one). To make it so that the file is *overwritten* if > it exists in the regular filesystem, we need to ensure that the next > critical component is in place (see next heading): > > *READING FILES > *Files should be read from the virtual filesystem FIRST, and then from the > regular filesystem if they don't exist. Only one file with the same name > should ever be returned with preference to the virtual file. That way if a > file is supposed to be *overwritten*, the proper file from the virtual > system will be delivered. > > *CFDIRECTORY > *Listing directories should be transparent as well and result in a regular > list of files as if this was a normal filesystem. Files in the virtual > system would get priority, so if a filename exists in both the virtual and > standard filesystem, only the virtual file would be displayed (since that > means the original file was overwritten). As an optional bonus, a new column > can appear that specifies whether the file/folder is in the "virtual" system > or not (not sure about this, just threw it out there). > > *COMPLICATIONS* > The main complications that Vince mentioned are CONFUSION and LACK OF > FLEXIBILITY: > > the transparency of the virtual file system is potentially confusing > > If it is truly 100% transparent, which seems like that may be possible, it > wouldn't be confusing at all to do what you always have been doing. Just > don't think about it :) Where it might get iffy is if it were only 90% > transparent, and you had to make special little modifications. But even that > doesn't seem to bad. The only real difference, no how good we make it, is > that files aren't actually being persisted like someone may expect in a > regular filesystem. But i think its still in the developer's responsibility > to know what platform they're on. For example, if I persisted my files to a > RamFS partition on my linux box, I am sure nobody would think it's OpenBD's > fault when I realise that my files were gone after a reboot. > > doesn't allow the coder to explicitly say, "I want this file to be read from > > > the virtual file system." > > This point is very important because what if you weren't just porting an old > app but wanted to build something brand-new with snazzy algorithms that take > advantage of the 2 filesystems in GAE? You should definitely be able to do > that as cfml isn't just a toy afterall. In this case, the developer can have > the *advanced* options available. If they really wanted to specify > gaefilesytem=virtual instead of the default gaefilesystem=merged (or > whatever) that should be allowed. We already have these platform-specific > attributes in cffile with 'mode' and 'attributes' for linux and windows, > it's not a far stretch to add GAE and AMAZON or jiggy the existing > attributes to accept more values. > > *SUMMARY > *I don't consider transparency and flexibility to be mutually exclusive. The > default behaviour can, and should, allow the user to treat the filesystem > like any other. While special atrributes can give a power user the ability > to over-ride those defaults. One thing is for sure, the value of being able > to seamlessly deploy an app on GAE should not be underestimated, and in my > opinion, should trump most other challenges. > > Cheers, > Baz > > > > On Wed, May 13, 2009 at 2:30 PM, Brad B. <[email protected]> wrote: > > > >Maybe. Have you looked at it? Can you give me a summary of how they've > > >implemented it? > > > Not in a while. But I believe its close to your #2 choice. > > It would make sense to first check for the existence of the virtual > > file system mapping before checking the disk though. > > > Regarding the large file support, it seems to me that a virtual file > > system for OpenBD GAE could be done for the datastore AND any future > > implementations of data storage. So if you've done enough to move > > ahead on this first implemenation you may want to go ahead and finish > > it and add a way of extending this for future iterations of the > > appengine api for data storage. > > > On a seperate matter how difficult would it be to include support for > > java/groovy classes for the Google Datastore methods googlewrite() > > googlequery() etc...? I'm guessing you're serializing cfc components > > for these functions. As they works now however, if you use any sort of > > DI on an entity cfc, or use a java entity the datastore methods fail - > > which makes them less useful.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ Open BlueDragon Public Mailing List http://groups.google.com/group/openbd?hl=en official site @ http://www.openbluedragon.org/ !! save a network - trim replies before posting !! -~----------~----~----~----~------~----~------~--~---
