[kforge-dev] environments, applications, services?

[John Bywater]

Rufus Pollock wrote:

> Wow, and I thought you were just going to write a few sentences. I 
> think your points are all excellent.


Thanks.

> 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).


Those, and things like the service's billing service and other customer 
services, are all ancillary to the delivery of the system function. So 
the "whole item" is the provision of the application as a web-based 
service, rather than on a CD with an EULA.


>
> Options seems to be:
>
>   * environment: trac uses this but overloads use of environment in 
> other circumstances (e.g. shell)
>     * John: -1
>     * Rufus: 0


This isn't an option.

>   * instance:
>     * ??


I don't this is a real option, because nobody uses instance to talk 
about a service.


>   * 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


This is the only option! :-) There might be indistinction, and a call 
for disambiguation, but there isn't any confusion (at least, in the very 
clear way Spinoza defines confusion). It's just a matter of saying which 
service you're talking about.

In the first analysis, surely we can agree that it's a service?

The modern world does prepare one conceptually to deal with a composite 
of services, such that a KForge ASP operation would provide a bundle of 
services, one of which is a software application service that (in 
KForge's case) provides a bundle of other services (which may include 
user support, billing, other customer services; and operational support 
services such as the other KForge services you mention - none of which 
should be mistaken for the production service, which motivates their 
existence, and to which they provide support).

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


Do you really dislike "service" half as much as a dislike "environment", 
whilst remaing indifferent to "service"? :-)

John.


>
> ~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
>
>
> _______________________________________________
> kforge-dev mailing list
> kforge-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/kforge-dev
>
>
>