Re: [ogpx] Draft work on Foundation and Type System

[David W Levine <[e-mail]>]

[e-mail] wrote on 03/01/2010 03:10:25 PM:

> [image removed] 
> 
> Re: [ogpx] Draft work on Foundation and Type System
> 
> Joshua Bell 
> 
> to:
> 
> ogpx
> 
> 03/01/2010 03:10 PM
> 
> Sent by:
> 
> [e-mail]
> 
> On Mon, Mar 1, 2010 at 11:56 AM, David W Levine <[e-mail]> wrote:
> 
> > ... and the (independent?) axis of "does this need to be 
> > standardized at the VWRAP level at all?" 
> >   
> The answer to the later, is yes if you ask me. If we can't describe 
> how the regions speak to the rest of the world, we're not actually 
> going to have interop, we're either going to have insanely painful 
hand-off 
> between clients, or an informal, non specified set of rules everyone has 
to 
> follow. 
> 
> Oops - what I wrote was unclear. 
> 
> To avoid confusion, let me clarify: by "does this need to be 
> standardized?", I meant the following three closely linked ideas:
> Does this individual message/set of related messages even make sense
> in an interop standard? For example, the current protocol has a 
> content transfer system layered over UDP. I would speculate that 
> VWRAP would use plain old HTTP rather than (say) attempting to 
> recreate the current system as LLSD-over-EventQueue-over-HTTP!
> As above, but there may be parts of the protocol where might agree 
> to replace detailed, special-case messaging with generic 
> functionality - for example, as Linden has done recently, replacing 
> a whole sub-protocol surrounding search queries and results with 
> "here's the URL of a Web page". In which case, the standard may 
> include that such a URL is expected to exist, but nothing beyond that.
> And to be clear, by "be standardized" I did not mean "rubber stamp 
> what's in a legacy protocol", but the overall process to design and 
> document forward-looking, inter-operable versions.
> Discussing this face-to-face might prove beneficial. :)
> 
> Joshua

Right. So.. To be equally clear. 

1) I certainly don't expect we'll codify what's on the wire today.
2) I do expect that that we need to end up with a formal shared approach 
to several types
   of non REST get/post messaging. 

   In particular:

    a) genuinely idempotent, discardable ones
    b) Certified HTTP like ones
    c) Possibly, and less clearly, streams of "events" -- I think there is 
a funny question of how one manages "continuing event subscription" 

And yes, a face-to-face may help. Umm. How about the end of this month?

- David
~ Zha