Re: streaming/push "out of scope", was Re: on API Requirements

On 02/23/2015 10:38 AM, Bill Looby wrote:
> I think we cmay need a 'Works With' section (I'm sure there's a better 
> name) for things that we need to ensure we are not blocking, but whose 
> definition are not core to the project.
Just a proposal, please feel free to rename, move etc.
https://www.w3.org/wiki/Socialwg#Further_Work

> 
> A defined list would make it easier to refer to during discussion and 
> allow us to put stakes in the ground as to the degree to which we are 
> willing to include support.
> 
> The Authentication system mentioned would be another example as in a 
> federated system especially, identification, authorization and 
> authentication may need clear support statements.
> _________________________________________
> Bill Looby
> Software Architect, Dublin Software Lab, IBM Ireland
> _________________________________________
> 
> 
> 
> 
> From:   ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
> To:     Sandro Hawke <sandro@w3.org>, Evan Prodromou <evan@e14n.com>
> Cc:     public-socialweb@w3.org
> Date:   23/02/2015 08:54
> Subject:        Re: streaming/push "out of scope", was Re: on API 
> Requirements
> 
> 
> 
> Sandro, what do you think about keeping it on a back burner for now?
> 
> At the same time whenever we see that some choices in architecture may
> make streaming/push harder to add later, we will clearly raise such 
> concern.
> 
> On 01/31/2015 03:47 AM, Sandro Hawke wrote:
>> On 01/29/2015 04:30 PM, Evan Prodromou wrote:
>>> Everyone is blown away by the size of these requirements already.
>>>
>>> A streaming protocol for streams would be a great addition later, but
>>> trying to jam it in here will literally sink this project.
>>>
>>> Please accept this as being out of scope.
>>
>> I might be misunderstanding what you mean by "out of scope".  To me, in
>> a WG, "out of scope" means "we're not even going to talk about this
>> issue, because it's not the kind of problem our charter says we're
>> supposed to talk about".  In general, it's up to the chairs in guiding
>> to conversation to steer it away from things that are out of scope (in
>> this sense) given their reading of the charter.
>>
>> What I think you're saying above is that you don't think streams/push
>> should be one of the requirements for the API.   That's plausible, but
>> maybe we can label that as "Not a requirement", instead of "out of
>> scope"?    That is, it's up to the group to come to consensus on what
>> the requirements for the API are, and you're arguing this should not be
>> one.  I'm sympathetic to your argument, but I'd also be interested in
>> hearing whether likely vendors of this stuff think they can sell systems
>> without streaming/push.
>>
>> The alternative interpretation is that maybe you think our charter
>> doesn't allow us to even consider this as a possible requirement, that
>> it's out-of-scope for the group.   Like, an authentication system would
>> surely be out-of-scope, and Harry was just arguing that WebFinger is out
>> of scope.
>>
>>         -- Sandro
>>
>>>
>>> Evan Prodromou
>>>
>>>> On Jan 29, 2015, at 15:00, ☮ elf Pavlik ☮
>>>> <perpetual-tripper@wwelves.org> wrote:
>>>>
>>>>> On 01/29/2015 02:21 AM, Sandro Hawke wrote:
>>>>>> On 01/28/2015 06:13 PM, Evan Prodromou wrote:
>>>>>>
>>>>>>> - Can you justify most of the out-of-scope stuff?   Without 
> streaming
>>>>>>> or push, I don't see how this system could catch on.
>>>>>> I think that server-to-server stuff is going to be more pertinent 
> when
>>>>>> we discuss the federation protocol.
>>>>> Clients need streaming/push, too, don't they?
>>>> +1
>>>>
>>>> in my experiments a while ago i used HTTP + JSON based pub/sub 
> protocol
>>>> Bayeux: http://svn.cometd.org/trunk/bayeux/bayeux.html
>>>>
>>>> using one of its implementations: http://faye.jcoglan.com/
>>>>
>>>> mentioned decentralized prototype with real time geolocation map 
> layers:
>>>> https://github.com/dspace-ng/dspace-app-action-slim
>>>>
>>>>
>>
>>
> 
> 
> 
> 

Received on Monday, 23 February 2015 09:52:23 UTC