Does Argotic have a role in intra-application comms?

Topics: Argotic.Core, Request For Comments (RFC)
Jul 23, 2008 at 3:21 PM
Hi all,

Short version:  if I want to use Argotic fully within my application, does the data have to go "out of process"?

Long version:

I'm designing a .Net desktop application that allows users to maintain an application-area specific diary.  I'm going to be using Atom with application-area extensions for the data storage format.   It had been my intention to use a .Net DOM manager to maintain the diary as single large object (feed).   With the feed size (~200 entries) and entry change frequency (one every two minutes or so), I think DOM item management (CRUD) would be fine.

Since reading about Argotic, however, I've started to realise that there may be future benefits in decoupling the data storage.  By using Atom APP it may become an option to let a web-server based process manage the data, or to let the client view data from a number of separate diary feeds.  If I did expand in this way in the future, then Argotic would be the natural solution.  But, do the newsgroup readers think it would introduce an unnecessary performance burden when everything is running locally?  It would be unfortunate if the UI component has to send the data "out of process" on it's way to the Argotic component.

I'd appreciate any related thoughts.

Jul 24, 2008 at 5:07 AM
You may consume and persist Atom Feed Documents and Atom Entry Documents using Streams in the framework, as well as being able to create you own custom data providers, so the answer to does the data have to go 'out of process' is no. If however you are talking about utilizing the Atom Publishing Protocol, that protocol is inherently tied to the HTTP transport protocol. An aggressive caching strategy coupled with conditional GET retrieval might be utilized to provide a responsive smart-client experience.