Hi Gregg,
Gregg Wonderly wrote:
Mark Brouwer wrote:
It seems you want to prevent from downloading JAR files that is driven
by the codebase annotation (the codebase annotation contains the encoded
PREFERRED.LIST [1]). I believe you want to prevent from downloading JAR
files due to limited bandwidth you have over WAN connections.
I want to have 100 services visible to a client, and discovery to not
cause any codebase references and thus force downloading because of
PREFERRED.LIST inquiries.
I understand the requirement of minimizing JAR file downloading,
although I take the following measurements to accomplish that:
1) partitioning of download JAR files, the codebase annotation points
to a dl.jar that is created by Seven while installing services and
thas uses JarWrapper and that only contains an INDEX.LIST,
MANIFEST.MF and PREFERRED.LIST. The size is around 1 KBytes and
refers to a lot of small download JAR files that can efficiently be
downloaded through the usage of INDEX.LIST. ServiceUI attributes
have their own download JAR files so these are not downloaded when
no ServiceUI needs to be instantiated;
2) Seven (upcoming) utilizes a persistent JAR file cache (through a
custom jar: protocol handler) that will check through an
if-modified-since whether download JAR files have been updated.
If not modified or no connection can be established once downloaded
JAR files are accessible by the class loaders. This is also extremely
important if you have data that relies on the availability of
codebases.
The above gave a dramatic reduction in download JAR traffic and a huge
saving in boot times for services that have been seen once by the JVM. I
realize that this requires a lot of plumbing, but I just want to
demonstrate that a lot of what you try to prevent can also be prevented
without any changes to codebases as is.
You have to consider that I also have my reef project changes to Reggie
active too. Thus, I can select when the service or any Entry values are
deserialized.
My service registrations include Entry values such as service names,
icons, javax.help files (referenced by URLs) etc. I want to be able to
display to the user, icons for all visible services without
unmarshalling anything except the bare minimum which is needed to show
the user icons and names.
I believe with a proper partitioning of your download JAR files you can
get very far. I'm not saying that this is an easy task though. There is
no way to prevent your service proxy to be unmarshalled and these can be
rather large. There are tricks possible there (lazy instantiation of
working parts through reflection) but this can get ugly.
To me it looks like you want the client to be the discriminator whether
classes (and thus the download JAR file) should be downloaded and not
the server through the PREFERRED.LIST it provides in the codebase
annotation, why do you want to turn that around?
I have a known platform that my services adhere to. That platform is
expressed in the PREFERRED.LIST explicitly, but is also expressed in the
I think I don't understand what you mean with the platform being
expressed in the preferred list as there is no notion of platform in the
semantics for preferred list.
I realize that some services assume a certain platfom to be available to
be able to work (their minimum platform) and that might differ from e.g.
the JTSK Platform. That is fine, but I always though of using an Entry
for that purposes, an entry that would be part of the minimum Jini
Platform on top of which another Platform could be defined, so the Entry
could be recognized by each and every Platform.
I haven't given it much though but it seems codebase or preferred list
feels the wrong place for specifying a platform. Codebase indicates
where the class definition(s) for some marshalled object can be obtained
and preferred list how class delegation should take place. A Platform
means to me the assumptions made by the service for it to be usable by a
client. When it doesn't meet the minimum platform it will likely fail
for some of its operations.
jar content and the classloader behavior implicitly. I want the
platform that the service is asserting to be conveyed to the client as
part of the service registration, not as part of the services codebase
You really try to prevent from any form of downloading :-) and I'm
afraid that if we are going to allow meta-data in the codebase we get on
a slippery slope (I still see problems with the increase of data due to
all those 'larger' annotations).
content. This would allow the client to decide whether or not it could
be compatible with that platform, early on.
I think a Platform Entry together with proper partitioning of download
JAR files can get you very far, but I realize that unmarshalling the
service proxy is still problamatic. If a combination of proper
partitioning and maybe some enhancements to ServiceRegistrar we might
get even further.
[1] I guess the codebase annotation is getting rather large that way
(although RFC 2616 doesn't seem to place any a priori limit on the
length of a URI you might run into problems in reality due to this) and
I think the various marshalled streams don't optimize on recurring URIs
(no URI table I can detect for classes with the same annotation) so you
will be consuming additional bandwidth (a lot?).
What I would say is that it's not part of the URL, but rather part of
the structure of the annotation string, which would break compatiblity
with arbitrary RMI applications when using the JRMP exporter. I.e. you
I think we should stick with URL/URI for codebase annotation, but I
think that still leaves some room for encoding meta-data if we come up
with useful meta-data.
This, is just my initial thought of a trivial to implement solution for
getting the information into the codebase string. It might be more
compatible to use
return codebase+" pref:/"+URLCoder.encode( new String(data) );
to make the additional information be recognizable for what it is.
The PreferredClassLoader would be changed to look at the annotation for
the defined separator ('\n' or " pref:/" or whatever) and use that
PREFERRED.LIST content instead of downloading one or more jars and
extracting it.
What if we come up with a scheme that allows for encoding of meta-data
that when not understood can be ignored and works as normal (downloading
of JAR file(s) to obtain meta-data) but can be utilized by those who
want to do that for whatever purpose.
Also what I don't understand at this moment is why a platform identifier
is not sufficient, why do you want to communicate the whole preferred
list. If you know the platform there are hooks to customize your
delegation model (in Seven I do the same thing, there is a platform
definition that controls the exact delegation model, so service can't
hike upon some implementation details). In such a case if a class is not
part of the platform it needs to be downloaded at which point you can
trigger the initial download of the JAR file that contains the
PREFERRED.LIST.
Just some thought because I really can't oversee all the implications.
--
Mark
