It sound like there is a consensus here to agree to disagree. Having
said that tongue in cheek, I'd have a few configurations issues I'd like
to propose as it pertains to rendering.
I've put it fixed font if it looks odd, change the font to a fixed version
The drawings are simple 2 node systems. The systems represent
integration points. You'll notice there are 2 interconnects between the
systems. A rendered format and a logical model. I discriminate between
the two, because, I believe they are two separate issues in terms of
interoperability.
I'm looking for consensus that these are the 4 simple models we will
most likely encounter in deployments.
-gary
1) OCCI Native Configuration
------------------ Native OCCI ------------------
| | Format | |
| System A |<---------------------->| System B |
| | | |
------------------ ------------------
System A Model <========================> System B Model
----------------------------------------------------------------------------------------------------------------
2) OCCI Adapter Configuration
---------------------------------------
------------------ Native OCCI |-----------
------------ |
| | Format || OCCI |<----------->|
System B | |
| System A |<---------------------->|| Adapter | Foreign |
(Foreign)| |
| | |----------- Format
------------ |
------------------
| |
--------------------------------------
System A Model <========================> System B Foreign Model
Model Transform
----------------------------------------------------------------------------------------------------------------
3) Foreign Adapter Configuration
---------------------------------------
------------------ Native Foreign |-----------
------------ |
| | Format || Foreign |<----------->|
System B | |
| System A |<---------------------->|| Adapter | OCCI |
(OCCI) | |
| (Foreign) | |----------- Format
------------ |
------------------
| |
--------------------------------------
System A Foreign Model <=================> System B OCCI Model
Model Transform
----------------------------------------------------------------------------------------------------------------
4) Gateway Configuration
------------------ Native Foreign ----------------- Native
OCCI ------------------
| | Format | |
Format | |
| System A |<------------------->| OCCI Gateway
|<------------------->| System B |
| (Foreign) | | |
| (OCCI) |
------------------ -----------------
------------------
System A Foreign Model
<===================================================> System B OCCI Model
Model Transform
----------------------------------------------------------------------------------------------------------------
Sam Johnston wrote:
On Tue, May 12, 2009 at 10:23 PM, Tim Bray <Tim.Bray@sun.com <mailto:Tim.Bray@sun.com>> wrote:
For JSON it's a lot less clear (at least for the famous
enterprise users) due to the support, copyright, patent, etc.
status surrounding third-party implementations. I know at
least some of my clients have policies that would require
developers to write the parser themselves - granted not a
particularly difficult task but an unnecessary and error prone
one.
We must live in different worlds. The Java programmers I know are
like "Yeah, JSON, whatever", and for .NET,
http://www.google.com/search?q=json%20.net turns up lots of stuff
including from Microsoft's own Codeplex. Javascript/Python/Ruby,
no problem. PHP I have no first-hand info, but since half the
Ajax-heavy sites in the planet are PHP-backed, I can't imagine
it's an issue. -T
Perhaps we do [live in different worlds]. Where I come from people would rather have silent phones <http://blogs.gartner.com/lydia_leong/2009/05/11/the-perils-of-defaults/> than risk changing a default setting. Opaque binaries and their updates pass without question while third-party/open source implementations are held up for months in convoluted approval processes (if not flat out banned). "Simplicity" translates to "Complexity" (so does "Complexity" for that matter).
One of the reasons I'm pushing the point is because I'd actually like to be permitted to use the fruits of our labour.
Sam
------------------------------------------------------------------------
_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg