File sharing, locking, etc... between multiple users...

[Jonathan Lynch]

I just want to say, Jim, your ideas on this topic are greatly appreciated.

Please share all of the here, as many of us might use them, or adapt them to
our needs.

Take care,

Jonathan


On 2/17/06, Jonathan Lynch <jonathandlynch at gmail.com> wrote:
>
> The way I am setting it up, the user will always know who has locked out
> the task file - it tells you when you open it, in a field in the upper left
> of the task viewer card.
>
> I intend to include instant messaging, either as a substack of Task Mage
> or as a separate stack in Work Mage. That way, a user who wants access can
> instant message the person who has it locked and tell the to get out.
>
> Which is not perfect.
>
> Your idea about stacking data chatroom style is a good one, I will give it
> some thought. A given task file, in task mage, is way more complicated than
> a simple field, so it might not be practical - but it bears thinking about.
>
> Thanks,
>
> Jonathan
>
>
>  On 2/16/06, simplsol at aol.com <simplsol at aol.com> wrote:
> >
> > WOW Jim,
> > These are some really good (extremely creative) ideas! Thank you for
> > sharing them.
> > Paul Looney
> >
> > -----Original Message-----
> > From: Jim Ault <JimAultWins at yahoo.com>
> > To: How to use Revolution <use-revolution at lists.runrev.com >
> > Sent: Thu, 16 Feb 2006 08:59:36 -0800
> > Subject: Re: File sharing, locking, etc... between multiple users...
> >
> >    As a design hint from my little corner of the world, you might think
> > of this
> > massive challenge along the lines of "event looping".  Every part of the
> >
> > solution actually operates on its own event loop and timing, sorta like
> > people attending a cocktail party.
> >
> > Everyone has there own agenda for enjoying the evening, their own
> > requirements, preferences and behaviors.  There are, however, limits and
> >
> > rules.
> >
> > Be careful of customer-driven design.  I have been there many times and
> > had
> > to defend the cogent database structure in spite of pressure to 'just
> > make
> > it work by Friday'.
> >
> > If you would like a few tips or design ideas, contact me off the list.
> > I
> > did an accounting system that worked on the principle of messaging,
> > queues,
> > conditions, and error checking.  One of the concepts that helped me was
> > 'semaphore' that signaled when tasks needed to be done and when and
> > where
> > they were located.  Kind of like "Is everybody here" when you don't
> > know who
> > "everybody" should be.
> >
> > Object-oriented-style seemed to make sense to me, and I did this in
> > Hypercard in the late 80's.  Of course, they were all Mac.
> >
> > Each day was its own object, worried only about its data and results,
> > then
> > knew when it was to be archived.  Each day was a stack that had its own
> > functions depending on the day of the week (Fri was different from Wed,
> > etc)
> > and time of the month (the last week was different than the first).
> >
> > This scheme allowed me to give each stack all the room it needed to deal
> > with its nature, including holidays, snow closures, etc.  Each day-stack
> >
> > would report in on a schedule + when queried.  Each card in the
> > day-stack
> > served a purpose.  Friday had more cards than a Tue (like employee hours
> > summary), unless a particular Tue was the end of the month.  You get the
> >
> > idea.  The "day stack creator" would make my day the way it needed to
> > be,
> > and then the day was self-sufficient, no matter which computer/hard
> > drive it
> > was on.  If it were on a back up drive, it would know that (Rinaldi
> > XCMD) by
> > asking the parent stack for the current drive list locations.
> >
> > Navigating from stack to stack for the manager and account was a snap,
> > since
> > that is something that HCard does very well.
> >
> > I also did their point of sale software in Hypercard,
> > object-oriented-style.
> > They sold Macintoshes mail order.  They were the first and very
> > successful,
> > until purchased, then died.  Had fun on the softball team :-)
> >
> > As usual, this may be of no help whatsoever with your circumstance.  In
> > that
> > event kindly disregard this morning wake-up tome.
> >
> > May Task Mage have good Luck Mage.
> >
> > Jim Ault
> > Las Vegas
> >
> >
> > On 2/16/06 6:53 AM, "Jonathan Lynch" < jonathandlynch at gmail.com> wrote:
> >
> > > The company my wife works for is starting to use Task Mage, because
> > they got
> > > fed up with MS Project
> > >
> > > This is great, because it gives me a customer driven process for
> > further
> > > development of Task Mage.
> > >
> > >
> > > One of the things they need is to be able to have shared use of
> > tasks, which
> > > are stored at a remote location and accessed via FTP. This is all very
> >
> > > doable, and I have made good progress in setting this up.
> > >
> > > But wow, sharing and locking files gets very complicated. The basic
> > model is
> > > simple, but the details, and cascading changes involved are just a
> > huge pain
> > > in the bahonkus.
> > >
> > > That's it, that's all I wanted to say... Just venting as parts of my
> > brain
> > > ooze out of my ears.
> > >
> > > Jonathan
> > > _______________________________________________
> > > use-revolution mailing list
> > > use-revolution at lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > subscription
> > > preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-revolution
> >
> >
> > _______________________________________________
> > use-revolution mailing list
> > use-revolution at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription
> > preferences:
> > http://lists.runrev.com/mailman/listinfo/use-revolution
> >
> >
> > _______________________________________________
> > use-revolution mailing list
> > use-revolution at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-revolution
> >
>
>