specifying what services Activities may use

[Greg Smith]

Hi Guys,

I hear you that defining dependencies and APIs is a tough challenge. As 
someone else mentioned, many projects do it effectively so we can do it 
better too.

I'm not partial to any particular parsing of the data. Maybe the 
activity developers have an opinion...

The key points are:

1 - When can we announce "no more changes" and activity developers can 
do a final test? Hopefully we give enough notice for them to fix 
anything that is broken before the release.

2 - Where and when can we document the changes in 8.2.0 which may affect 
activity developers?

Is your categorization getting us closer to that?

I think we know what to do but if its still not clear we can get an 
activity developer on the phone (or IRC) and they can tell us what they 
need. It has to be a listening meeting with no push back or argument. 
They tell us what they need and we figure out how well we can respond.

That's one idea for moving forward but perhaps we have all we need from 
this thread and just need to write it down.

Morgan's related thread ([sugar] Proposal: Activity developers mailing 
list) will help improve communication so it may all come together if we 
strike while the iron is hot!

Thanks,

Greg S

Erik Garrison wrote:
> On Wed, Jul 30, 2008 at 12:03:52PM -0400, Michael Stone wrote:
>> On Wed, Jul 30, 2008 at 11:03:41AM -0400, Greg Smith wrote:
>>> Hi Daniel,
>>>
>>> We need a list of anything that might "break" an activity. 
>> The list of things that have to work in order for an activity
>> (particularly a networked one) to "work" is larger than the memory and
>> comprehension of any individual working on this project. It includes
>> nasty things like
>>
> 
> Is this a reasonable categorization?:
> 
> kernel version dependent:
> 
>>    * syscall semantics
> 
> system library dependent:
> 
>>    * availability of language interpreters
>>    * library APIs
> 
> nasty things we tend to change:
> 
>>    * file-system layouts
>>    * authorization data like file-system permissions
> 
> ouch!:
> 
>>    * statistical biases in the outcomes of non-deterministic computations
>>    * computational complexity of default algorithms
> 
> 
>