- We are looking at the next major steps in the building process.

- We need to get off the single instance of our program running. We are trying to get to a clustered type configuration/interface.

- This is a list of the shared resources on the servers

- images (12 photo galleries), logos, alternate logos, watermarks, csv, some PDF's, part categories may have images, snow owl theme has some defaults, ecommerce default images, browser tab icons, images out in ecommer land (sending file references through API sockets).

- To pull it down a bit, images for the 12 players, look and feel stuff, custom utilities (csv's and PDF's).

- The CSV files are created and used immediately.

- There are some PDF stuff like labels, merging into multiple labels, public wavier type stuff, barcode images, QR code images

- Name for the project - shared files service

- We are going to create a shared file service object - to start with, we want the services to look to the older, shared folders, for these assets and/or files (images and what not). At some point, we would like to switch out this service so that it could point to the new location. We want the backend pointer to be flexible so that we could change it if needed.

- At some point, we will actually need to move all of the resources to the new location (say the content server). This could be a pretty big migration process.

- There may be a series of requests that build and save things locally (just like normal) and then it also queues up another request to sync and/or update on a different storage location.

- If we make a request to this service... what do we need to tell it? For sure corp id, server name or server address, what files are needed, etc.

- Some of our shared files (such as images) are used and called in different ways. For example: Parts are dealt with differently than invoices and those are different then customer images. All 12 main players are slightly different. We would need to standardize those things. We could use a custom tag that interfaces with the service layer.

- Potential to set some of these shared file paths in the session scope and then build all of the pages based off of that. We are really interested in the main source or location for the URL. The main login or switching corps are both major triggers that we need to catch and reformat the URL to those shared files. Once we have it, through the service, we store it in session scope.

- The init phase - we need a reasonable default value to start with. We talked about using corp 1, 22, or 53. Long story made short, we need a safe starting value and/or default.

- What about white label options. We talked about using a default corp of 1 (unassigned). We also talked about default logos that are not adilas specific. An idea from Alan, each person is tied to a single home planet (home corp), maybe use that as the inti or default look and feel until they say something different by switching corps.

- It might be good to go in and get a precise list of visual elements that are needed. At the same time, we may want to make all of these visual elements non brand specific (looking towards more white label options).

- We also talked about the fact that eventually, we want to split out the users from the different corps. They would have a master user id and then be tied to other local boxes and databases.

- We could build an automated process to help migrate some of those pieces. At the same time... we could standardize the names of the logos, alternate logos, and watermarks. We could rename some of the assets as needed to help standardize things. We talked about standardizing the logo name as well as the logo extension (say .png as a default).

- There are a ton of image file format tools out there. Originally, we were limited to certain file types and options. Not some of those limits have been removed.

- As a side note, we have a need to do multiple file uploads.

//////////////////////////////////

Switching to a group project type build out

- Turning to the building and training process - Wayne really wants to get some of the test driven design in place and get the guys doing testing and passing those tests.

- Baby steps - add a parameter, go test, add a parameter, go test, etc.

- Trying to instill best practices

- Wayne will have a testing repo called "testing_adilas" - We will all use that repo (code repository) for all unit testing.

- Wayne is going to be focusing on the "process" of doing this as a group. There will be some mistakes and problems, but we will use those obstacles as learning opportunities.

- There may be some homework projects and passing pieces off to others in the group.

- Letting everybody dive in and write some code.