Data vs Code

[Derek O'Connell]

Just a thought for the future, I noticed my local repo is starting to expand significantly due to fixtures/legacy-db's. Should ref-only data such as icd10, drugbank, etc, be kept separate from the repo and downloaded on-demand in production? Also the general advice is avoid storing binary data in repo's (fixtures need not be binary but for the data mentioned they will most likely be eventually supplied in their final binary format, eg, sqlite/postgresql db, ie, as legacy db's).

-D

[Easwar TR]

Hi,

I am just having the same thoughts. Removing the 'big' fixtures, binary data that can be regenerated by scripts are to be done. Just yesterday, I contributed more to this bloat by pushing a commit that has another set of queries stored as .yaml. Most ill advised. My bad.

So, this what I think can be done.

1) Switch to Postgres ASAP and leave it to the user while installing to generate the DB

2) Small data can be provided as fixtures, but larger data like ICD10 , DrugBank, FDA Drug list can be either a python script that can generate the fixture / DB. This can be run based on the user at install time. I'm thinking of user profile like approach which allows you to switch on of off features at time of installation. Some thing like a PHP app thats lets you install selected "Extra features" at install time. I've not given thought on how to do this with Django. An approach I can think on top of my head is to actually creates an 'Installer" app that orchestrates all the setting up.

The down side to that ala carte approach would be that the DB row with foreignkey to ICD 10 NULL = False in applications like "Medical History", "Surgical History" cannot be set before hand and will have to be set on the fly based on whether the ICD app is going to get installed or not. With Django will require some effort ( please see Will Hardy's link I sent you earlier about dynamic models).

An approach to handle whether the DB row will alow NULL value setting based on whether the application is installed or not would be something like this pseudocode:

icd10 = models.ForeignKey(null = get_module('icd10) , blank = get_module('icd10')

return value from a function 'get_module' that tries to import the 'ICD10' would be False if the app is not installed and True if installed

How does that sound ?

Again, but how will a user who decides to add in the ICD later cope with this ? Will he have to edit the DB schema by hand or use Django-migrations (improved support in Django 1.7) ? This is the question I asked myself and decided probably the 'registry' app along with the sub-apps goes into AuShadha as a stock app. Of course now we have to contend with providing efficient queries along with preventing bloat.

In fact, I had kind of foreseen this bloat to some extent. Hence the attempt to make AuShadha pluggable. In long run my idea was to create an AuShadha-core and some stock applications. Only the core will be in the present AuShadha repo. All the plugins / applications will reside in Au-Pluggable repo.

If we were to roll out PyPi packages, then user can install the applications that are needed alone using pip install. We can provide a 'Requirements.txt' for add on modules that are expected to work well with that release of AuShadha-core ( The Zope 3 KGS analogy) . However, this would be a additional step for installation and will require maintainence a lot many packages in separate repos.

For me, it seems to be a toss between a how to provide a basic package with an efficient query system but one which is slightly bloated with one that is in separate packages (more maintanence ) and where we may have to handle dynamic django models.

Hope I am clear. Any ideas ?

Easwar

On Sun, Apr 13, 2014 at 1:12 PM, Derek O'Connell <doco...@gmail.com> wrote:

Just a thought for the future, I noticed my local repo is starting to expand significantly due to fixtures/legacy-db's. Should ref-only data such as icd10, drugbank, etc, be kept separate from the repo and downloaded on-demand in production? Also the general advice is avoid storing binary data in repo's (fixtures need not be binary but for the data mentioned they will most likely be eventually supplied in their final binary format, eg, sqlite/postgresql db, ie, as legacy db's).

-D

--
You received this message because you are subscribed to the Google Groups "AuShadha" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aushadha+u...@googlegroups.com.
To post to this group, send email to aush...@googlegroups.com.
Visit this group at http://groups.google.com/group/aushadha.
For more options, visit https://groups.google.com/d/optout.

--

 

Dr. Easwar T.R  MBBS, DNB(Orth.), MNAMS
   Fellowship Paediatric Orthopaedics & Deformity Correction( Sing., Kor.)
   Fellowship Spine & Scoliosis Surgery (Kor.),  
   Spinal Microsurgery (Ger.)

 Consultant Paediatric Orthopaedic & Spine Surgeon

     Ph:      91-98407-24924  

    Web:   www.dreaswar.com

    Email: drea...@gmail.com

[Derek O'Connell]

On Sunday, 13 April 2014 17:39:13 UTC+1, dreaswar wrote:

Hi,

I am just having the same thoughts. Removing the 'big' fixtures, binary data that can be regenerated by scripts are to be done. Just yesterday, I contributed more to this bloat by pushing a commit that has another set of queries stored as .yaml. Most ill advised. My bad.

So, this what I think can be done.

1) Switch to Postgres ASAP and leave it to the user while installing to generate the DB

Postgres, ok.

Should such db's be generated on the user's end or supplied pre-cooked with the associated plug-in? Downside of generating on-site is you still have to deliver the XML with AuShadha or provide an on-demand download mechanism. Former is impractical given the size of some of the XML data sources and the latter option you might have to do anyway (eventually)...

2) Small data can be provided as fixtures, but larger data like ICD10 , DrugBank, FDA Drug list can be either a python script that can generate the fixture / DB. This can be run based on the user at install time. I'm thinking of user profile like approach which allows you to switch on of off features at time of installation. Some thing like a PHP app thats lets you install selected "Extra features" at install time. I've not given thought on how to do this with Django. An approach I can think on top of my head is to actually creates an 'Installer" app that orchestrates all the setting up.

The trend seems to be to manage plug-in's internally with the advantage that you gain greater control over the process, can regularly check for updates and be independent of whatever mechanism is first used to install AuShadha. For examples I'd point at Eclipse and browser add-on's.
 

The down side to that ala carte approach would be that the DB row with foreignkey to ICD 10 NULL = False in applications like "Medical History", "Surgical History" cannot be set before hand and will have to be set on the fly based on whether the ICD app is going to get installed or not. With Django will require some effort ( please see Will Hardy's link I sent you earlier about dynamic models).

Re dynamic models, I'd like to digest it further and see real-world use-cases. Given the side effects I'd question the cost vs benefits of such an approach and, like meta-programming, suggest it's only to be used if there is no other option (KISS rules!). So, excusing my ignorance, why would NULL=False be used if ICD10/whatever is optional?...
 

An approach to handle whether the DB row will alow NULL value setting based on whether the application is installed or not would be something like this pseudocode:

icd10 = models.ForeignKey(null = get_module('icd10) , blank = get_module('icd10')

return value from a function 'get_module' that tries to import the 'ICD10' would be False if the app is not installed and True if installed

How does that sound ?

To add to the above, it may be that once a user installs ICD10 (as a plug-in, post-install) that they *then* want this constraint but I'm betting there's a better way to handle this via indirection at run-time. Since your Django knowledge > mine, does that ring any bells for you? I'll look into it asap. Maybe I should "read-ahead" :-)...
 

Again, but how will a user who decides to add in the ICD later cope with this ? Will he have to edit the DB schema by hand or use Django-migrations (improved support in Django 1.7) ? This is the question I asked myself and decided probably the 'registry' app along with the sub-apps goes into AuShadha as a stock app. Of course now we have to contend with providing efficient queries along with preventing bloat.

I'm definitely seeing a case for a "core" set of plug-in's.

I don't think there will be any conflict between bloat and queries. After the regular job of removing redundancy data is-what-it-is. Yes, it might grow a little for convenience but that is likely to significantly improve query performance (or completely avoid some queries) and the trade-off, when/if needed. will likely be worth it.
 

In fact, I had kind of foreseen this bloat to some extent. Hence the attempt to make AuShadha pluggable. In long run my idea was to create an AuShadha-core and some stock applications. Only the core will be in the present AuShadha repo. All the plugins / applications will reside in Au-Pluggable repo.

Good foresight and planning! I'm probably stating the obvious but you have recognised the need to modularise AuShadha and now have to consider how to uncouple these modules, ie, make them less co-dependant. I view this process as similar to normalisation's "nothing but the key", ie, we smell another plug-in... a "medical coding" plug-in(/module) perhaps? Needs some more thought.
 

If we were to roll out PyPi packages, then user can install the applications that are needed alone using pip install. We can provide a 'Requirements.txt' for add on modules that are expected to work well with that release of AuShadha-core ( The Zope 3 KGS analogy) . However, this would be a additional step for installation and will require maintainence a lot many packages in separate repos.

Maybe just a repo or two for "good" and "untested" plug-in's? See comment above re managing plug-in's internally (sorry this stuff isn't presented more linearly).

Re any remaining/other custom install issues, if you were to go the pypi route, isn't "setup.py" specifically for this purpose?
 

For me, it seems to be a toss between a how to provide a basic package with an efficient query system but one which is slightly bloated with one that is in separate packages (more maintanence ) and where we may have to handle dynamic django models.

Hope I am clear. Any ideas ?

Yes very ckear and I hope I have been clear and that my ideas make sense :-) If not I'll try better tomorrow. It sure would be good to have a wiki to capture this stuff in an organised manner.

-D
 

[Easwar TR]

  

Postgres, ok.

 

Should such db's be generated on the user's end or supplied pre-cooked with the associated plug-in? Downside of generating on-site is you still have to deliver the XML with AuShadha or provide an on-demand download mechanism. Former is impractical given the size of some of the XML data sources and the latter option you might have to do anyway (eventually)...

The trend seems to be to manage plug-in's internally with the advantage that you gain greater control over the process, can regularly check for updates and be independent of whatever mechanism is first used to install AuShadha. For examples I'd point at Eclipse and browser add-on's.

 

So, when shall we move to Postgres ?

Plugin -manager... that'll be another app

Installer will be another app

Makes sense.

Installer sets up the core and asks you whether you want more. If not we go ahead with stock. If yes it hands over control to plugin-manager at that time.If you want anything later plugin-manager will take care of that. What abt Uninstall / upgrade ?

 

Re dynamic models, I'd like to digest it further and see real-world use-cases. Given the side effects I'd question the cost vs benefits of such an approach and, like meta-programming, suggest it's only to be used if there is no other option (KISS rules!). So, excusing my ignorance, why would NULL=False be used if ICD10/whatever is optional?...

 

Ya, metaprogramming should be avoidable. That said, Django makes heavy use of the same to get its models the way it is. Am attaching two preliminary files that I am polishing up for models via YAML which I talked about. (See attached files )

 

To add to the above, it may be that once a user installs ICD10 (as a plug-in, post-install) that they *then* want this constraint but I'm betting there's a better way to handle this via indirection at run-time. Since your Django knowledge > mine, does that ring any bells for you? I'll look into it asap. Maybe I should "read-ahead" :-)...

This definitely looks like a job for migrations. Will have to read up. on this. Oh, by the way a quick call to is_mine_django_gt_yours() returns False :)

 

I don't think there will be any conflict between bloat and queries. After the regular job of removing redundancy data is-what-it-is. Yes, it might grow a little for convenience but that is likely to significantly improve query performance (or completely avoid some queries) and the trade-off, when/if needed. will likely be worth it.

Currently, as per my readings on S.overflow and the like, this seems to be a discussed topic. How to efficiently query large data in Django. Django iterators and some snippets are discussed. 

Good foresight and planning! I'm probably stating the obvious but you have recognised the need to modularise AuShadha and now have to consider how to uncouple these modules, ie, make them less co-dependant. I view this process as similar to normalisation's "nothing but the key", ie, we smell another plug-in... a "medical coding" plug-in(/module) perhaps? Needs some more thought.

Actually icd10, icd10_pcs, drugdb, fda_medication_list all are 'medical coding' apps or more generically 'registry' apps. They are plugins. The only question is to whther offer them ala-carte or bundled and if bundled how to reduce the bloat (relatively) and still perform an efficient query at runtime.

As for uncoupling, I have almost fully uncoupled AuShadha. Please delete/ move all folders save the registry, patient and AuShadha folder. It will still search. You can even remove the patient folder. It will not cause an error. The Search pane will load. Of course youll have to appropriately modify the settings.py but thats it.

I have used a 'Role based' module / class import system through out. An instance of AuShadhaUI class is set up at server start and this instance stores as attributes classes in installed apps. This is done my looping over aushadha.py in each of installed apps. This is very similar (and inspired) from Django's own method in contrib.admin app along with my Zope 3 interface hangovers.

This allows easy swaping. For eg. for now lets say the role of "DrugDatabase" is performed by DrugBankCa app that you have parsed. So, we'd register this with the AuShadhaUI class calling UI.register('DrugDatabase', <DrugBankCaClassName>). Later if we develop any alternate database or if say, this is used in some other continent ant they want to swap it for their own drug database we can just remove the DrugBankCa app and use that other app which would also do a similar registration UI.register('DrugDatabase', <AlternateDrugDBClassName>). There will be no import errors.

Maybe just a repo or two for "good" and "untested" plug-in's? See comment above re managing plug-in's internally (sorry this stuff isn't presented more linearly).

Re any remaining/other custom install issues, if you were to go the pypi route, isn't "setup.py" specifically for this purpose?

We can have a general repo and status of each plugin. This would be similar to Dojo's own approach with regard to their Dojox library collection. Each Dojox plugin has a status label : 'maintained', 'experimental', 'abandoned' etc...  But as I am writing this Dojo 2.0 seems to be moving away from this and making everything into one repo for tight integration. Life seems to be going round and round :)

Yes, I've put in setup.py, MANIFEST.in etc for this purpose. this was put in much before the discussion in the groups. Ive not tested whether they even work. :)
 

Yes very ckear and I hope I have been clear and that my ideas make sense :-) If not I'll try better tomorrow. It sure would be good to have a wiki to capture this stuff in an organised manner.

Wiki ? I thnk the internal Sphinx docs should be the place. Last time I put up wiki and somebody kind of spammed it, I had no time to maintain it. It still is experiencing 'technical difficulties' :)

Easwar

[Derek O'Connell]

Just a quick clarification of my comment re "medical coding plug-in": I
meant as an intermediary/container type arrangement not related to any
specific coding scheme. This is the "indirection" I was referring to.
It's also, in my mind, equivalent to having two related tables with
foreign keys and the "nothing but the key" step involves creating a
third table that just stores the related keys. So the "medical coding
plug-in" would act as a stand-in for any specific coding making other
plug-in's independent of any specific coding (or absence there-of).
Beyond that I haven't given it any more thought and sorry if I failed to
explain it better. Have I done so now?

Btw, I'm clear about the modularisation-via-plug-in's that you have done
so far and didn't mean to imply otherwise. In old-school terminology
"modularising" is one thing, "decoupling" to reduce co-dependence is
another. Issues related to decoupling are sometimes subtle and not
immediately obvious (the extreme solution is "Functional Programming"
you'll be happy to know ;-) ).

PostgreSQL, installed, haven't use it in years but I'll switch as soon
as I have familiarised with it.

I have some urgent planning to do for some work later this week but will
re-read your email in detail later today.

PS: I like your icd10-pcs view! I'm planning to add filtering based on
keywords & synonyms when I've finishing re-jigging the db to avoid those
initial queries.

-D

> this. Oh, by the way a quick call to *is_mine_django_gt_yours()* returns

> False :)
>
>
>> I don't think there will be any conflict between bloat and queries. After
>> the regular job of removing redundancy data is-what-it-is. Yes, it might
>> grow a little for convenience but that is likely to significantly improve
>> query performance (or completely avoid some queries) and the trade-off,
>> when/if needed. will likely be worth it.
>>
> Currently, as per my readings on S.overflow and the like, this seems to be
> a discussed topic. How to efficiently query large data in Django. Django
> iterators and some snippets are discussed.
>
> Good foresight and planning! I'm probably stating the obvious but you have
>> recognised the need to modularise AuShadha and now have to consider how to
>> uncouple these modules, ie, make them less co-dependant. I view this
>> process as similar to normalisation's "nothing but the key", ie, we smell
>> another plug-in... a "medical coding" plug-in(/module) perhaps? Needs some
>> more thought.
>>

> Actually icd10, icd10_pcs, drugdb, fda_medication_list all *are* 'medical
> coding' apps or more generically 'registry' apps. They *are* plugins. The

> only question is to whther offer them ala-carte or bundled and if bundled
> how to reduce the bloat (relatively) and still perform an efficient query
> at runtime.
>

> As for uncoupling, I *have* almost fully uncoupled AuShadha. Please delete/

> *Dr. Easwar T.R* MBBS, DNB(Orth.), MNAMS
> * Fellowship Paediatric Orthopaedics & **Deformity Correction( S**ing.,
> Kor.)*
>
>
> * Fellowship Spine & Scoliosis Surgery (Kor.), Spinal Microsurgery
> (Ger.)*
> *Consultant Paediatric Orthopaedic & Spine Surgeon*
>
> *Ph*: 91-98407-24924
> * Web*: www.dreaswar.com
> * Email*: drea...@gmail.com
>

[Easwar TR]

Ah,
Thanks for clarifying the medical plugin thing. Nice idea ... Almost like a linker module. Borrowing zope again would it be an Adapter ?
Anyway, thanks for clarifying.
Glad you like my views.

Dr. Easwar T. R. DNB(Orth.), MNAMS

Consultant Paediatric Orthopaedic & Spine Surgeon

www.dreaswar.com

--
You received this message because you are subscribed to the Google Groups "AuShadha" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aushadha+unsubscribe@googlegroups.com.
To post to this group, send an email to aush...@googlegroups.com.

[Derek O'Connell]

I'm not familiar with Zope but "adapter" sounds right. Just found this
which frames it as a pattern, haven't read it yet...

http://ginstrom.com/scribbles/2009/03/27/the-adapter-pattern-in-python/

>> email to aushadha+u...@googlegroups.com.

[Derek O'Connell]

On 15/04/14 09:18, Easwar TR wrote:

> Plugin -manager... that'll be another app Installer will be another
> app Makes sense. Installer sets up the core and asks you whether you
> want more. If not we go ahead with stock. If yes it hands over control
> to plugin-manager at that time.If you want anything later
> plugin-manager will take care of that. What abt Uninstall / upgrade ?

The tricky question is what to do with any end-user data (generated by
using a plug-in). Obviously it has to be preserved during an upgrade,
possibly massaged in rare (hopefully) cases. If a plug-in is removed
then the user should be given the option to delete such data. If they
choose not to delete it and later re-install the plug-in then that
dictates that plug-in's need to check for data on install and
use/massage if found.

I'd like to leave this discussion to a later date. Seems a common
requirement so I'm sure there are plenty of existing implementations to
learn from.

> Ya, metaprogramming should be avoidable. That said, Django makes heavy
> use of the same to get its models the way it is. Am attaching two
> preliminary files that I am polishing up for models via YAML which I
> talked about. (See attached files )

I've looked at your files and earlier post. How far do you intend to go
down the "framework" route? Is there a distinction between providing a
degree of flexibility and reproducing Zope/Plone/Etc features? I can
understand the motivation for giving the user some control over, eg,
layout/styling but doesn't defining models in YAML go a lot further into
"framework" territory? Not criticising, just trying to get a feel for
direction.

Unrelated: do you have any experience of django-cms or mezzanine?

>> To add to the above, it may be that once a user installs ICD10 (as a
>> plug-in, post-install) that they *then* want this constraint but I'm
>> betting there's a better way to handle this via indirection at run-time.
>> Since your Django knowledge > mine, does that ring any bells for you? I'll
>> look into it asap. Maybe I should "read-ahead" :-)...
>>
> This definitely looks like a job for migrations. Will have to read up. on

> this. Oh, by the way a quick call to *is_mine_django_gt_yours()* returns
> False :)

The evidence proving otherwise is plain to see ;-) You might be
understating your expertise but I'd bet it exceeds some Django dev's.

> Wiki ? I thnk the internal Sphinx docs should be the place. Last time
> I put up wiki and somebody kind of spammed it, I had no time to
> maintain it. It still is experiencing 'technical difficulties' :)

Wiki, restrict the editors? I was thinking more for a place to air
ideas, get feedback, make plans, etc. Trawling emails is a time
consuming and a real chore but I won't badger you about it any further.

Many interruptions this week, back to actual coding this afternoon :-)

-D

[Easwar TR]

1) Plugins, installation, uninstalltion:

Yeah, I think we'll leave it for later and would probably want to do some home work on this. I suppose its safe to assume that as long as we stick to basic principles of modularity / decoupled apps, it should be possible to implement this later. The user-data is tricky. Thats something that needs thought. Especially if there are FKs and then you remove app itself to which the FK belongs. How will that be handled. Will it then do a downstream cascade delete when user decides to remove that. What if some of the models on which the cascase delete is being performed downstream are not being removed. It gets murkier. Needs a lot more thought and a dedicated thread. Useful discussion though.

2) Frameworking

How far to go ? Well, thats a good question ( especially because I dont have a clear answer). The reason I decided to framework AuShadha a little is to make developing new apps easy. More importantly, make customising existing apps ( beyond styling ) easy. This is out of my own experience with Open Source EMRs. It was so difficult to make even a small change in the fields to customise the data collection.

How far I intend to go ? Hm.. you see, this was not something I gave lot of thought to. Plain answer is I really dont have a end point in mind when I started doing this.

The whole YAML thing started with a ConfigParser experiment. I wanted the User to customise the UI in someway. HTML as way too wordy - HTML tags, JS everywhere. So started this Config Parser way of specifying the UI got fed up and switched over to YAML. It now seems acceptable proposition as people with no Django / Python knowledge can kind of change the layout easily.

At the time I started out on this I was thinking only about styling and layout of the UI. Slowly, I thought the same thing about models. Right now if a user changes a field, he has to change the field in models, views, templates, js, etc.. so many places have to be maintained. So even a slight customisation needs to be tested. The way I was thinking about this was, ( again Zope inspired ) that we need to make the object aware of the things it can do ( CRUD and other actions), its URLS (which is a reflection of the things it can do), its data ( the models ) and the way it is rendered (template). In a way I was thinking about the entire app as a kind of 'mega object' which will have all the MVC elements as attributes. The files I sent you were part of the experiment. I shared these with you mainly so that you can tell me if there is something wrong with my approach ( both programming and planning wise ). The files i sent you cover only the models part of it (the M of MVC ).

As I type this I read your mail about 'reverse' in YAML  -- This is something that is referred to earlier as to the URL awareness of each object. I will reply in detail on that thread but would like to add a link to a Zope topic on this:

• http://reinout.vanrees.org/weblog/2011/06/07/zope.html
• http://www.stereoplex.com/blog/adapters-in-django-and-the-revenge-of-zope

The second link will be of interest as at several places in AuShadha views ( refer to paient apps views.py ) you''ll find me coding if getattr(<obj>, 'urls', None) is None: <obj>.save()

When I started AuShadha, I was having lot of trouble with the 'reverse'. When called with args / kwargs it simply would not pass through as expected. If there was a regex match you had overlooked that figured in urls.py before the intended url, it would call the wrong view function. Even a named url would'nt go through. For me it didnt seem right. Inspired by the Zope solution (the second link), but not wanting to include zope.interface / zope.component packages into AuShadha, I created a 'lousy' but kind of working UrlGenerator class ( find it at src/AuShadha/AuShadha/utilities/urls.py ) that generates all the URLS that an object is capable of. My idea was to merge the UrlGenerator base class into the ModelBaseClass once created along with a GenericViewClass. So done like this each model is aware of the data it has to hold, its data structure, the view, the template and actions it can do on itself and other related objects.

Again, partly Zope inspired, where each object can be specified as a Container and itself can Contain other explicitly specified objects. This is why in model definition you'd find me giving stupid instance attribute names such as 'can_add_list_or_json'. Basically what I mean to say is that I give permission to the 'add' ,'list', 'json output' the contained objects. If I dont specify that here, then the URLS wont be generated. Think of it like a permission sort of thing.

In Django things start with urls.py. It provides the to-do list of sorts which sets up your views and then links you model to it. Zope goes the otherway. You design your schema and then build your app around it with loosely coupled adapters and views. Well, I suppose in a way its up to the developer and how his/her brain is wired.

I had lot of trouble with 'reverse' initially, but when I was coding the YAML I toyed with reverse again and to my surprise found that it was working. So I used it extensively from that point on using 'named urls' either as calls to 'reverse' or {%url %} template tag.  As far as YAML template goes i'd stick with the {%url%} template tag method for its readability and its ability to pass all the args you want. What ever work I did with the UrlGenerator object is just left as legacy. I'd remove that soon unless you think I've stumbled on something here.

I hope I could explain clearly some of the rationale on why you find things the way they are.

Getting back to the question of how far I want to go with this. Well, I dont have a clear answer now. Right now I'd keep this very much in the Au-Labs :). This is not a priority now. Right now please think of it as a wild experiment by a Zope damaged brain.


3) Wiki

Well as you wish. I'll set it up for you and give you the keys. :)

You can comfortably put and group all your notes and discussions there.

-D

--
You received this message because you are subscribed to the Google Groups "AuShadha" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aushadha+unsubscribe@googlegroups.com.

To post to this group, send an email to aush...@googlegroups.com.

Visit this group at http://groups.google.com/group/aushadha.
For more options, visit https://groups.google.com/d/optout.

--