————————————————————————————————————————————————————————————————————
Thanks for the feedback.
There are two predominant reasons why I believe this should be included as part of the core API.
First, the JXTA core is currently unable to use JXTA transport mechanisms for internal operations such as the loading of Modules. At best, it can currently only handle HTTP URL references. This means that the entirety of the JXTA vision with respect to module deployment has yet to be fully realized. For trivial deployments where the module implementations are pre-distributed this isn't much of a problem but when you have complex network topologies combined with dynamic module loading this becomes plainly evident. I started into this development after hitting my head on exactly this problem. I can't see how this problem can be solved outwith the inclusion of a core API.
Second, this is one of the most common use cases that shows up in the user forums. Since JXTA is a network abstraction it needs to excel at exposing multiple low level transports in a higher level form independent of those transports. Currently, JXTA exposes messages (limited in size and unreliable) and sockets. Messages are unwieldy to use for arbitrary content sizes since the content needs to be packetized, support retries, etc.. Sockets are a bit better in both these regards since they implement reliability and flow control but they tend to require the user to re-invent the portions of content transfer relating to the transferred object's meta data (type, size, checksum, etc.) and progress. Note also that the net.jxta.socket API is not technically a must-have feature as it simply wraps piped messages within reliability and flow control constructs. It was added into the core API for the same reason - to lower the barrier of entry to JXTA.
Again, the first reason noted above was the primary driver. Not being able to use JXTA for loading JXTA seemed a bit of an irony to me. :) Hope this help clarify/justify,
Mike
On Wed, Jul 23, 2008 at 4:11 AM, <the....@sympatico.ca> wrote:
Though the application scenario is valid, I don't think the service is needed because the task can be easily accomplished by the existing JXTA features. Only must-have features should be added into the JXTA core. Apparently the proposed service does not qualify as a must-have feature.
When I transfer my arbitrary data (serialized objects, video, music, images, etc....), I simply encode them in BASE64 into an XML element and put it into an advertisement, then sign it and publish it. Simple, safe and sound. It works perfectly for me.
From: "Mike Cumings" <mcum...@gmail.com> Reply-To: de...@jxta.dev.java.net To: de...@jxta.dev.java.net Subject: [jxta-dev] New ContentService API committed into trunk Date: Mon, 21 Jul 2008 21:44:32 -0700
Hello all,
I've been waiting for this for a long time... ;)
I got the go-ahead from bondolo to commit a new content transfer service (read: CMS replacement) into the subversion trunk. The primary intent is to expose the API to a larger audience so that we can resolve any API issues prior to it's release in the next JXSE release.
So what is the ContentService?
The ContentService is simply a service interface which can be used to transfer arbitrary data (Content) from one Peer to another. Content is shared by one peer which then provides access to an advertisement for that share. A remote peer becomes aware of this share advertisement (typically, but not necessarily, via the DiscoveryService) and can use the advertisement to initiate a transfer session to retrieve the remote data.
In addition to the basic functionality, the ContentService API was constructed to be pluggable and supports any number of ContentProvider implementations concurrently, each of which have the ability to support or ignore incoming API-based requests. It is the ContentProvider which performs the actual sharing and transfer of the content. This allows specific classes of data to be intelligently shared by a provider implementation which has in-depth knowledge of that class of data. The initial commit includes two very rudimentary implementations, one which is a trivial, TFTP-like implementation and another which leverages JxtaSockets. These implementations are intended to be replaced before too long with something more robust, scalable, and possibly standardized between the JXTA bindings. In the event that this pluggable implementation is not desired, directly replacing the ContentService is also possible. Alternatively, all providers can be programmatically added/removed/accessed after the ContentService has been initialized and started, allowing the programmatic removal of dynamically added provider implementations (via, e.g., the Jar SPI mechanism).
Asynchronous updates relating to the status of the share/transfer are exposed programmatically via events. This includes events on the server-side relating to the active shares as well as events relating to client-side transfers in progress.
Perceived benefits of this work primarily consist of the following: 1) This work can be used for further improvements to the core JXTA loader mechanism, allowing for module implementations to be retreived over JXTA-native transport in addition to the current HTTP support. 2) This also provides an easy, standard, and simply method to move data objects from one peer to another with minimal programmatic handling, lowering the bar for inexperienced JXTA developers.
Once things seem generally accepted on this alias, we can open it up to the web forums and user alias as well.
Please take a walk through the API and let me know where it seems rough. Feedback (including/especially criticism) welcomed! Enjoy,
-- Mike Cumings
Example server code snippet:
ContentService service = new ContentServiceImpl(); service.init(netPeerGroup, ContentService.MODULE_CLASS_ID, null); service.startApp(new String[0]); ContentID contentID = IDFactory.newContentID( netPeerGroup.getPeerGroupID(), false); FileDocument fileDoc = new FileDocument(file, MimeMediaType.AOS); Content content = new Content(contentID, null, fileDoc); List<ContentShare> shares = service.shareContent(content); DiscoveryService discoService = netPeerGroup.getDiscoveryService(); for (ContentShare share : shares) { ContentShareAdvertisement adv = share.getContentShareAdvertisement(); discoService.publish(adv); }
Example client transfer initiation code snippet:
ContentService service = new ContentServiceImpl(); service.init(netPeerGroup, ContentService.MODULE_CLASS_ID, null); service.startApp(new String[0]); ContentTransfer transfer = service.retrieveContent(contentID); if (transfer != null) { transfer.startTransfer(new File("content")); }
-- Mike Cumings