[kforge-dev] environments, applications, services?

[Rufus Pollock]

Wow, and I thought you were just going to write a few sentences. I think 
your points are all excellent. My one concern is that the term Service 
in ASP is used more to denote the whole item. For example we might talk 
about providing the knowledgeforge service based on the KForge software 
but this might involve having several 'instances' of KForge installed 
(testing, sandbox, 2 to use for a stepped upgrade process).

Options seems to be:

   * environment: trac uses this but overloads use of environment in 
other circumstances (e.g. shell)
     * John: -1
     * Rufus: 0
   * instance:
     * ??
   * service: related to ASP. potential confusion between meaning of 
'KForge service' (service [domain object] in a KForge service or just 
the KForge service)
     * John: +1
     * Rufus: -0.5

Currently we are using 'environment'. Once a decision is made this can 
be changed.

~rufus

John Bywater wrote:
> We have written some Python software called KForge.
> 
> One can install it, and then provide various different KForge 
> application services using the same installation. You can also install 
> KForge a number of times, so different installed versions can be run 
> separately on the same machine.
> 
> Just now in KForge, such an application service has been named 
> "environment".
> 
> Although this follows Trac, I think it is a terrible name, because 
> environment usually denotes that which surrounds and conditions a being, 
> rather than directly denoting a being as such.
> 
> Rather than Trac, I propose we follow a broader and more established 
> current. The term Application Service Provider (ASP) has been around now 
> for many years, and seems not to have distributed confusion throughout 
> the world.
> 
> As such, I would propose we adopt these terms and definitions:
> 
> 1. Application. Something one can install. An application of software 
> written in an established software programming language (to include: the 
> idea of the system, the system design, the working code--installed or 
> otherwise).
> 
> 2. Service. Something installed. "An instance of an application", or 
> "the affect supported by the working code" - "it's features, 
> capabilities, or function", "what it was designed to do" (to include: a 
> service provided by installing an application, regardless of whether or 
> not the installed application is capable of supporting various different 
> services from the same single installation, and regardless of whether or 
> not various different services are provided using one or many different 
> installations of the application).
> 
> 3. Provider. Somebody who installs something. Human beings responsible 
> for delivering the affect of the working code (the service) to client 
> users.
> 
> I propose this irrespective of the objects of KForge.
> 
> Particularly I don't propose to avoid a supposed "collision" with the 
> Service object in the KForge domain model. Indeed, the usage of the term 
> 'Service' in KForge conforms with the above meanings: a service in 
> KForge is an instance of the set of affects of a (plugged-in) software 
> application.
> 
> In summary, one can download Trac a software application. One can 
> install the download, and provide a Trac application service.
> 
> One can also download the KForge software application. One can install 
> the download, thereby creating a "service of KForge" (another 
> application service).
> 
> Then, one can use KForge to provide many Trac application services 
> within the KForge application service. This is because the KForge 
> software application supports plugging in the Trac software application. 
> When services are provided using KForge in this way, we could denote 
> them either as "services in KForge" or as "a KForge service of a 
> particular plugin".
> 
> To be meaningful, the word phrase "a KForge service" does need adequate 
> context to provide disambiguation between the alternative meanings: 
> "service of Kforge" or "service in KForge".
> 
> So when we speak about services and KForges we must try to be clear 
> about what we are talking about. It shouldn't be too hard to indicate, 
> or to ask.
> 
> We could give services of KForge individual names. For example, we use 
> the name "KnowledgeForge" to denote the service of KForge provided by 
> the Open Knowledge Foundation at http://knowledgeforge.net/. The 
> KnowledgeForge service has a project called KForge, which has a 
> Subversion service, and a Trac service.
> 
> Does this make sense? I suppose, the fact that "service" is becoming 
> oversignified is merely the affect of the software industry's moving to 
> software-as-a-service (away from software-as-a-commodity, with 
> restrictive EULAs), as a continuation of the more general movement to 
> "service economy" (which as everybody knows, exists on the series: 
> commodity-service-relationship-brain-... :-) ).
> 
> Best wishes,
> 
> John.
> 
> 
> 
> 
> 
> _______________________________________________
> kforge-dev mailing list
> kforge-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/kforge-dev