On Thursday, January 30, 2014, Tanya Madurapperuma <[email protected]> wrote:
> > > > On Wed, Jan 29, 2014 at 10:49 AM, Chan <[email protected]> wrote: > > > > On Wed, Jan 29, 2014 at 10:43 AM, Chan <[email protected]> wrote: > > > > > On Wed, Jan 29, 2014 at 10:25 AM, Madhuka Udantha <[email protected]>wrote: > > > > > On Wed, Jan 29, 2014 at 3:27 AM, Nuwan Bandara <[email protected]> wrote: > > > > On Tue, Jan 28, 2014 at 1:19 PM, Afkham Azeez <[email protected]> wrote: > > > > > On Tue, Jan 28, 2014 at 11:06 PM, Nuwan Bandara <[email protected]> wrote: > > Hi All > > > On Tue, Jan 28, 2014 at 11:33 AM, Manuranga Perera <[email protected]> wrote: > > The problem ultimately boils down to this common scenario: > > a) A customer has a Jaggery app in their environment. > b) Some UI (images, css, headers, ect.) is customized > c) Now they find a bug and ask for a patch > > > +1, the issue here is all others replied here against patching a jaggery > app is because you think of a jaggery app as a "hello world" web app. But > you should look at the jaggery code in products like APIM / AppFac / UES / > ES / MDM. In all these products Jaggery app is the place that has the major > business logic. In these products Carbon is just the hosting environment. > These are full fledge applications that does all kinds of things, generate > meta data, has its own configurations etc, and when we find a minor issue > we cannot ask people to replace the entire app and reconfigure every thing > from the beginning. > > Just try the application developers shoes for a moment here and get out of > the midleware developer mindset; Imagine we have developed an application > and thats our main product. Now how do you fix problems in this product ? > will you be shipping new versions of the product always when you find an > issue ? If that is the case we will be shipping new versions of AS every > day ;) > > Also when there is a requirement we should not think about how it can be > squeezed into the existing model with minimum headache. We should find a > comfortable solution for the users not something comfortable to implement. > > > The requirement is to fix bugs in apps. The requirement is not, support > patching of webapps. The solution is to update the app through patch fileif > the app is > uses a textual scripting language, or redeploy changed or a new version, > if the app is in a compiled/binary/bytecode form. > > > +1, that should work, but we nee > > AFAIU this solution is not feasible as we have to maintain a separate git > repo for each customer. > As far as I know - we do maintain code bases for customers. Plus maintaining git repos for customers is realistically not a hard thing to do cause everything is scriptable in git. > It will become an issue when the number of customers grow. And also > customers with lesser developer knowledge will face issues in resolving > conflicts in merging etc. > If customers customize our jaggery apps which they will definitely do - they will version control it anyway and most probably they will use git. > > Patches approach is nice but thinking from an Application Developer stand > point version controlling is the best way to handle this type of patches. > Food for thought I guess. > > [1] - https://devcenter.heroku.com/articles/git > > > > On Tue, Jan 28, 2014 at 1:37 PM, Afkham Azeez <[email protected]> wrote: > > Cluster-wide patch distribution will be handle by the Operations Center. > > Azeez > > > On Tue, Jan 28, 2014 at 12:40 PM, Ruchira Wageesha <[email protected]>wrote: > > > > > -- > Tanya Madurapperuma > -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email [email protected] <[email protected]>* * ~Mobile +94712112165* * ~Website dulithawijewantha.com <http://dulithawijewantha.com/>* * ~Blog blog.dulithawijewantha.com <http://dulichan.github.io/chan/>* * ~Twitter @dulitharw <https://twitter.com/dulitharw>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
