Re: httpmd

Mark Brouwer wrote:
> Logan, Patrick wrote:
>
>> Do most people use httpmd at this point? Should they? Would there be a
>
> Only when codebase integrity is required and it hard to use when your
> clients are application servers e.g. that are not under your control, as
> you just found out it requires installing the additional protocol
> handler at the system classpath.
>

Curse the JDK for it's horrid way of adding URLHandlers......

> I don't know though how many people use httpmd only for its side effect
> (a new URI when the JAR files have changed).
>

And this is the important bit - httpmd isn't really designed to support
your class evolution wishes.

>> I decided to try out httpmd to see how easy it is to use, based on a
>> mailing list email I saw (sorry link not close at hand) suggesting
>> that the digest number is a good way to make changes to code result in
>> a new url.
>
> Remember though that you might have clients that still refer to an older
> codebase annotation (same URI when not taking the message digest into
> account) and that when they try to download the JAR file they will
> assume it has been tampered with. This might not be a problem with your
> usage of mobile code, but I've been bitten by that in the past.
>

Yep that's a possible gotcha.

Client's could indeed still be running but perhaps in dev, Patrick is
tearing them down anyways.

Patrick, a basic approach to dealing with retirement of codebase
annotations is to control/bound their spread and be aware of how many
clients are using a service.  Note I'm being deliberately vague here as
I have some interesting stuff in this area.

> I have two golden rules "Never delete a codebase annotation URI once
> served, the so called Cool URIs [1]." so when changes occur in your
> download JAR create a new URI, regardless of the protocol use in your
> codebase annotation. This has also some side-effects, but unfortunately
> not all issues around mobile code can be solved due to the way how the
> Java type system works.
>

More JDK'isms, mutter.

Or at least arrange for new versions to have different .jar names.  We
can argue about the tradeoffs of keeping old codebase annotations live
another time.

> [1] see http://www.w3.org/Provider/Style/URI
>

Thanks for the reference.

>> I guess I am starting to think about a development environment that
>> keeps things running as much as possible and tools that cleanup those
>> things that need a fresh start. That's a big topic, and this is just
>> my first little step -- trying out httpmd.
>
> Did you already look at some other frameworks than what is provided as
> part of the JTSK that solve many of the problems you will encounter when
> working with Jini, such as evolution of download JAR files (which is not
> an easy and efficient task to do by hand)?

:)

Remembering that those frameworks potentially bring their own
baggage/requirements with them which may or may not be "compatible" with
the needs of the user.

> --
> Mark
>

Take care,

Dan.

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]