Regarding renaming files: The .cpp and .h file names need to correspond with .idl names, which in turn correspond with the interfaces specified in these .idl. The later are standard, user-facing strings. This means that you can't change them without fixing a lot of generation and build rules. If your goal is reducing complexity, this might not be a good idea.
On Tue, Aug 31, 2010 at 3:02 AM, Jeremy Orlow <jor...@chromium.org> wrote: > On Mon, Aug 30, 2010 at 5:17 PM, Darin Fisher <da...@chromium.org> wrote: > >> On Mon, Aug 30, 2010 at 9:11 AM, Maciej Stachowiak <m...@apple.com> wrote: >> >>> >>> On Aug 30, 2010, at 8:36 AM, Darin Fisher wrote: >>> >>> On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth <aba...@webkit.org> wrote: >>> >>>> On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak <m...@apple.com> >>>> wrote: >>>> > Yes. The file-related stuff should all be in one directory, I think. >>>> >>>> Ok. I moved the files from WebCore/html to WebCore/fileapi. >>>> >>>> On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote: >>>> > We have bunch of FileSystem (which is a part of File API) related >>>> files in >>>> > WebCore/storage/. >>>> > Maybe we should move them to the new directory too? >>>> >>>> Are these the files you're talking about? >>>> >>>> WebCore/storage/DOMFilePath.cpp >>>> WebCore/storage/DOMFilePath.h >>>> WebCore/storage/DOMFileSystem.cpp >>>> WebCore/storage/DOMFileSystem.h >>>> WebCore/storage/DOMFileSystem.idl >>>> WebCore/storage/FileEntry.cpp >>>> WebCore/storage/FileEntry.h >>>> WebCore/storage/FileEntry.idl >>>> WebCore/storage/FileSystemCallback.h >>>> WebCore/storage/FileSystemCallback.idl >>>> WebCore/storage/FileSystemCallbacks.cpp >>>> WebCore/storage/FileSystemCallbacks.h >>>> WebCore/storage/LocalFileSystem.cpp >>>> WebCore/storage/LocalFileSystem.h >>>> >>>> I'm happy to move them to WebCore/fileapi, but I'm also happy for you to >>>> do it. >>>> >>>> Thanks, >>>> Adam >>>> >>>> >>> >>> How about just moving everything into WebCore/storage? This is all >>> storage-related stuff. >>> >>> >>> I think the File API is large enough to deserve its own directory. In >>> fact, it might be worth splitting up the remaining contents of the storage >>> directory too. It is confusing to have large but almost entirely separate >>> APIs all piled into one directory. It is true they are all >>> "storage-related", but that is a pretty broad theme, and LocalStorage, SQL >>> Storage, Indexed DB and File API have little or no interaction with each >>> other. >>> >>> Regards, >>> Maciej >>> >>> >>> >>> >> That's fair. Plus, there are a lot of files in there already. >> > > What names should we use? > > WebSQLDatabase: > Like WebSockets, I think the "web" part is pretty important to keep people > from getting confused. 'websqldatabase' seems a bit long though. > 'websqldb' maybe? > > WebStorage: > Currently we call this "Dom Storage" throughout the codebase (including in > the ENABLE macro), so we may want to call it "domstorage". Like WebSockets > and WebSQLDatabase, I think "storage" with no prefix seems like a generic > storage directory so we should probably call it "webstorage" if "domstorage" > isn't acceptable. > > Indexed Database API: > "IndexedDB" is what it's commonly called, so a directory of "indexeddb" > seems like the way to go. > > J > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev