On Tue, Aug 31, 2010 at 5:57 PM, Yaar Schnitman <yaar@chromium.org> wrote:
No, the file names. The module part matters when IDLs refer to each other (typedefs and includes) - but these are easy to fix.
Can you give an example of what you're talking about? I can't remember seeing anything like this in the past. Also, is there a reason why they're necessary?
On Tue, Aug 31, 2010 at 9:00 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
You're talking about the "module" part of the IDL? Is that even used by anything or specified anywhere? As far as I can tell, the answer is no.
On Tue, Aug 31, 2010 at 4:54 PM, Yaar Schnitman <yaar@chromium.org>wrote:
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.
Sure... but the _directories_ are not user facing. That's all we're talking about here.
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 <jorlow@chromium.org>wrote:
On Mon, Aug 30, 2010 at 5:17 PM, Darin Fisher <darin@chromium.org>wrote:
On Mon, Aug 30, 2010 at 9:11 AM, Maciej Stachowiak <mjs@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 <abarth@webkit.org>wrote:
> On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak <mjs@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