Regards, Yusuke Suzuki On Fri, Jan 6, 2017 at 5:34 AM, Yusuke SUZUKI <utatane....@gmail.com> wrote:
> On Fri, Jan 6, 2017 at 2:37 AM, Brady Eidson <beid...@apple.com> wrote: > >> >> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI <utatane....@gmail.com> wrote: >> >> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler <da...@apple.com> wrote: >> >>> I understand the appeal of “org.webkit” and structured names but >>> personally I would prefer to read names that look like titles and are made >>> up of words with spaces, like these: >>> >>> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”. >>> “WebKit: JavaScript DFG Compiler” rather than >>> “org.webkit.jsc.DFGCompiler”. >>> >>> Not sure how well that would generalize to all the different names. >>> >>> I like the idea of having a smart way of automatically making a shorter >>> name for the platforms that have shorter length limits. >>> >> >> One interesting idea I've come up with is that, >> >> 1. specifying "org.webkit.ImageDecoder" >> 2. In Linux, we just use "ImageDecoder" part. >> 3. In macOS port, we automatically convert it to "WebKit: Image Decoder” >> >> >> Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder” >> part is ever going to be used? >> Is that because Windows could use “org.webkit.”? >> >> > Yup, we can drop this part. Originally, I was considering about > "com.apple.IPC.ReceiveQueue" > in WebKit2 thread => "Apple WebKit: xxx". > But I think just using "WebKit: " is OK. > > >> Again, back to Darin’s point, I don’t see any particular value in ever >> seeing “org.webkit.” >> >> Additionally, the way this proposal treats “ImageDecoder” as multiple >> words, presumably separated on case-change, is problematic. >> >> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”, >> different from today. >> e.g. “IndexedDBServer”, which is probably what this should be called, >> would expand to “Indexed D B Server" >> e.g. “GCController” would expand to “G C Controller” >> > > If we recognize the [UpperCharacter]*[LowerCharacter]* as word, we can > split it as "GC Controller". > Oops, I mean using ([UpperCharacter][LowerCharacter]) to split the word. > But anyway, it causes a problem when we encounter a name like > "XMLDBController". > > >> >> — >> >> Taking your proposal and running with it, I think we could do this: >> >> 1 - Specify the feature name with spaces: “Asynchronous Disassembler” >> >> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis” >> 2a - It could get truncated with ellipses: “AsynchronousDi…" >> > > I think we should not truncate the name for Linux. > My automatic shortening is based on the fact that "org.webkit.MODULE.NAME"'s > NAME part is always <= 15 characters. So we do not truncate. > > But if we have names like "Asynchronous Indexed Database Server" and > "Asynchronous Indexed Database Client", the both become "AsynchronousIndex" > in Linux. > It is not helpful. > > However always using 15 characters names effectively limits the ability of > macOS's thread names. > > So now, I like Geoff's idea, having 2 names, long name and short name. > For example, we have "Asynchronous Disassembler" and "AsyncDisasm". > Then, in macOS, use "WebKit: Asynchronous Disassembler". > In Windows, use "WebKit: AsyncDisasm". > In Linux, use "AsyncDisasm". > > >> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit: >> Asynchronous Disassemb” >> 3a - It could get truncated with ellipses: “WebKit: Asynchronous >> Disassem…” >> >> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous >> Disassembler" >> >> Addendum: If we see value in having somethings flagged as “JSC” instead >> of “WebKit”, we just augment the input to include that. >> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific >> feature could be “WebKit. IndexedDB Server” >> > > Yeah, we can add JSC prefix in long name part if we want. > > >> >> Thanks, >> ~Brady >> > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
