coapp-developers team mailing list archive

[C S Shyam Sundar <csshyamsundar@xxxxxxxxx>]

I'm Shyam from India.

I have a decent amount of experience in application packaging
and maintenance of OSS components in mixed environment in both native and
emulated (cygwin).

What's enthralling to me is - coapp aims to do what the company I worked 2
years ago, intended to do that time ( and failed ). I'm outlining what I
did, when we had no one sort of rules in place.

I worked for the India Development center of a  popular company that
specializes in providing business-ready open source software solutions.
One of our flagship products was called software factory as it built small
ISV's build infrastructure stacks like WAMP ( windows, apache, mysql, php ),
WAPP ( the same with PostgreSQL ) and Java stacks based on tomcat along
side integrating your new web 2.0 app. Our business model was based on
delivering support thru these stacks. ( Offering custom builds with
community patches, patches for 0 day exploits, and a single update channel,
etc. )

Our build system was based on gentoo's portage.
The builds for linux were a walk in the park as we leveraged on community
ebuilds.
For Windows, it  was quite a challenge., we made small changes to portage
system and made it run on Windows. As most of the infrastructure components
like Apache, PHP, etc. gave the VS Solution files, which made our jobs
easier to write custom ebuilds.However, for other components, we had to
write our own ebuilds and also create VS solutions. Mind that certain
components like libjpg still need VS6 to compile and wont compile in VS7 or
upwards.
Our toolchain had - VS6, VS7 and VS8. At that time, VS7 was out defacto
compiler, VS8 was experimental and VS6 was used for older incompatible
components.

Unlike coapp's vision, we decided to follow the linux way of deployment.
All our applications were deployed on one directory inside the root drive.
This directory had a directory structure similar to linux - like /usr, /var,
/lib, /opt, /etc.
All the high level infrastructure components like Apache, PHP, MySQL reside
inside /opt. The configs are inside /etc.
All the shared libraries lie inside the /lib., etc. Since it is windows,
integration along with windows services, etc. were put in place.

Ofcourse, we also had our hacked version of portage inside. This helped us
leverage it for update. We pointed portage's config to point to our servers,
which delivered tested components as update. Of course the config. backup
and restore was a bit tricky - but it worked for most people.

Our sales team had nearly 1800 ISV's sign up and use this service and
generate their custom stacks with their components, however, recession had
set in by then and I joined another company and rest is history.

coapp is interesting, but I'm wondering what its complete intentions are:

- whether it was it to port every OSS app and make it runnable in windows. (
something like what Mac Ports or Fink does )
or
- whether it is interested to maintain certain components ( if, yes, what
are those and what is the criteria, etc. )

Pardon my ignorance if the above were already answered -

Regards

Shyam