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. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 !! -~----------~----~----~----~------~----~------~--~---
