Difference between revisions of "PrplWrt Feed Considerations"

From PRPL
Jump to: navigation, search
(Components)
Line 20: Line 20:
  
 
=== Base system ===
 
=== Base system ===
 +
As described above, the base system of PrplWrt should always be an OpenWrt release.
  
 
=== Required packages & features ===
 
=== Required packages & features ===
 +
 +
==== High-Level API ====
 +
For the purpose of supporting the high-level APIs, the feed would need to have:
 +
* uBus
 +
* UCI
 +
 +
==== Service distribution ====
 +
Many of Prpl's members are working towards service distribution on broadband devices. The packages listed here are necessary to make that happen.
 +
* opkg
 +
* Python, JavaScript?
  
 
=== Packages that need replacement ===
 
=== Packages that need replacement ===
 +
Not all packages in OpenWrt can or should be used in an enterprise stack. This chapter aim to capture these and categorize according to the reason for their dismissal.
  
 
==== Licensing reasons ====
 
==== Licensing reasons ====

Revision as of 16:24, 22 November 2017

Description

A PrplWrt feed is the idea of creating an OpenWrt-based distribution that focuses on the needs of the fixed-net industry.

As such. the feed would:

  • Focus on stability and end-consumer readiness
  • Come exclusively with packages released under permissive licenses, such as Apache 2.0
  • Be driven by agreements and standards decided in Prpl working groups

At the same time, the PrplWrt feed would always be based on the latest OpenWrt release. With patches and contributions of value to the wider community being upstreamed whenever possible. The feed itself, in turn, would act as a sort of upstream for industry features which may include a full TR-069 integration, a carrier-grade IPC or service-sandboxing features.

Scope

A PrplWrt feed would not aim to be a full enterprise router or gateway OS. Instead, it is a framework to bootstrap the development of such an OS and serve as a solid development platform. Therefore, not every feature required on a carrier or retail router will be available in the feed itself. However, it's open nature would almost certainly ensure that a fitting package can be licensed from multiple software vendors.

Purpose

PrplWrt is designed to considerably lower the barrier for anyone interested in developing broadband / fixed-net services and software in an enterprise environment. This can mean service companies looking to create the next generation gateway services such as security services, smart firewalls etc. or hardware manufacturers aiming to move from their proprietary in-house architecture to a system based on open components. At the same time it will give carriers and ISPs is reliable basis for investments in broadband value-added-services as it makes the developments viable for use across multiple manufacturers and device generations.

Components

Base system

As described above, the base system of PrplWrt should always be an OpenWrt release.

Required packages & features

High-Level API

For the purpose of supporting the high-level APIs, the feed would need to have:

  • uBus
  • UCI

Service distribution

Many of Prpl's members are working towards service distribution on broadband devices. The packages listed here are necessary to make that happen.

  • opkg
  • Python, JavaScript?

Packages that need replacement

Not all packages in OpenWrt can or should be used in an enterprise stack. This chapter aim to capture these and categorize according to the reason for their dismissal.

Licensing reasons

Unfit for purpose

Life-cycle

Source donation

Package patrons

Distribution Maintainer

Package upgrades

Releases

Quality assurance

Certification

Commercial considerations