Hi,
Richard S. Hall schrieb:
Excellent work.
Thanks ;-)
Knowing that we might expect other forms of remote access, is
"shell.remote" the best name for this subproject?
Not sure either; it just came to my mind as a first idea and I kind of
liked it. We are also talking about "Simple Remote Shell".
Let's open debate on the name ;-)
This gets us back to our naming debate that started on the PAX Logger,
should we just give our subprojects names or should we try to categorize
them in some fashion? Categorizing is difficult because it can feel
forced, but also we don't always know in advance that we need
categories, so at some point we might find that we need to rename our
artifacts and since our artifact names match our package structure, this
can be painful to clients.
In this regard, just having names is better, because we don't have to
worry about it changing.
Over in Sling we structured also but also added the structure name to
the bundle name most of the times. So the bundle in scripting/core has a
bundle symbolic name ending in .scripting.core. We have exceptions, but
these are deliberate and sometimes even driven by compatibility
concerns. Still the last part of the bundle name is the name of the
directory the bundle source is contained in.
We could do a similar thing here: Create a folder structure such as:
.../shell
+- service
+- tui
+- gui
+- gui.plugin
+- remote
I think there is not an ultimate black or white solution to this problem
and it might have to be solved on a case-by-case basis -- as long as the
solution remains intuitive to a certain degree.
Regards
Felix
