[JXTA discuss] Proposal: CodatService and CMS

All,

Back story:

Over the last few months I've been working on and off on designing
and implementing a prototype project.  This project is intended to
provide a standardized JXTA service packaging mechanism similar
to web applications.  While thinking about how this would play
out I ran into the long-outstanding need for a way to properly move
module implementations across the JXTA network.

Current day:

Over the last few days I have been taking a look at Codats,
the CMS project (cms.jxta.org), the JXTA search project
(search.jxta.org), and have talked with a few JXTA developers
via the MyJXTA application.  All of this has brought me to
one conclusion which I'd like to discuss further: The splitting
of the CMS project into two pieces, one of which would
ideally be implemented in the core as a standard service.
Specifically, I think it would be beneficial for the following to
take place. Note that I expect this to be fairly controversial
and am posing it exclusively as a basis for discussion,
not a technical/meritorious attack:

#1 - Orient the CMS such that it deals with Codats instead
of Content.

   The distinction here is minimal as the functionality
provided by the Content and related classes mirror almost
exactly the functionality provided by the Codat core classes.
This would effectively remove the redundant definitions
provided by the CMS in favor of definitions which are
generic.
   Doing this would start filling a hole in the Java reference
implementation where a lack of utility API renders Codats
an effectively useless construct as they really only allow for
serialization and a stream interface (transfer of a Codat
from one peer to another is not directly supported)

#2 - Create a CodatService module to provision the transport
of Codat data from one peer to another.  The purpose of this
provisioning is to exclusively replicate Codat data - not to
provide listing or searching services beyond that which is
required to find a remote Codat definition and make a local
copy.

   Currently, the CMS acts like a proper CMS and allows for
searching and indexing based on metadata which is arbitrarily
applied to the notion of an unknown chunk of data.  Specific
examples are the Content name, description, and an ID
based on the hash of the data itself.  Additionally, metadata
for the Content is a separate construct altogether from the
Content class itself, unlike the Codat construct where
Metadata extends Codat.
   The CMS currently also provides an interface for remotely
listing the available shares of a peer.  I believe that the
ability to list the content which has been made remotely
available is the function of the application using the common
core (such as a CMS) and not the function of the core itself.
for this reason, this would define a boundary between where
a core CodatService implementation would end and the CMS
would (re)begin.
   Note that removal of the hash-based ID can be justified in
that each Codat will already be assigned a unique JXTA ID.
Validation of transferred data (another use for the hash) would
be implemented as a pluggable hook in the core library such
that A) existing functionality can be retained, B) this removes
the inherent binding of a ContentAdvertisement to static
content thereby allowing for dynamic data to be transferred, 
and C) alternate data validation mechanisms could be
selected on a per-application basis.  As statd in the previous
paragraph, search based on metadata such as the hash
would be application specific and as such be relegated to
code outside and above the core codat service - in this case
the CMS code.
   It is expected that the protocol implementation used for
such data transfers would be both simple and extensible.
Simple so that basic transfers can take place on limited
devices, extensible so that applications could potentially
leverage the protocol to layer more complicated behaviour.

#3 - Support the retrieval of Codat data from multiple sources.

   The CMS does not currently support this, though work has
been done (and is being done) to augment it with this capability.
Since Codat data is application specific, the validation of this
data - and as a result the sources of this data - must be
potentially validated by the application prior to inclusion in a
multi-source transfer.  The core codat service must allow
for this sort of data source approval to occur at the application
level.

#4 - Dramatically increase the event portfolio to allow for
finer grained visibility into the transfer process.

    The basic test which should be applied is: what information
is needed to create a nice graphical display for the end user,
provide sufficient programmatic control points, and yet conserve
compute resources.  If I recall correctly, the CMS currently
notifies upon completion, but not (for example) on progress.

#5 - Taking experience from other applications in the P2P
world, I also propose that resource usage throttling hooks
be provided to the application layer to give it the ability to
control knobs such as maximum bytes served per second,
etc..

   This would provide applications more control over what the
underlying core is doing, helping to preserve and enhance
the end user experience.

#6 - Finally, once this core is in place, add support for
Codat URIs into the reference JXTA loader such that
Module Implementation Source URIs could refer to Codat
URIs, retrieving the content of the Codat and attempting
to instantiate classes using the Codat as a data source.

   This finally gets the long-desired ability to move into
place services around the network *using* the network.
Once here, powerful activities can ensue without
dependence on non-JXTA transport mechanisms.  I submit
that this functionality is critical to the ultimate goal of
JXTA: decentralised, heterogeneous network of things.


In conclusion, while the above is large in textual content
it should be noted that the existing CMS provides much
of the functionality already.  This API reorganization would
simply split the current CMS implementation into a
base, generically defined substrate on which the more
complicated operations would be overlaid.  It should also
be noted that although I've though of potential
implementations of the underlying layer, I'm not specifically
proposing any particular implementation within this
email.  I just want feedback (but please be nice)!

Thanks in advance,

-- 
Mike Cumings