Viewing meta data creates continuation

Hi Lenya devs,

everytime the meta data tab is requested, a continuation is
created. 
Even if you modify and save the meta data, another
continuation is 
created, because the screen is displayed again. This
behaviour 
unnecessarily increases memory consumption.

I see two options to avoid the problem:

1. Don't create continuations
2. Separate "modify meta-data" usecase

The major problem with approach 1. is that it doesn't detect
read-write 
conflicts - with concurrent modification, the second commit
overrides 
the changes of the first one. This is especially problematic
with our 
current approach: All meta data values are saved, not only
the modified 
ones.

Approach 2. requires additional clicks, but I think we could
live with that.

How about this approach: The meta data screen has no submit
button by 
default, but next to each (editable) field is an
"Edit" button. When you 
click it, an optimistic usecase is started, which only
manipulates this 
single field. The "Edit" button changes to
"Save". The changes are sent 
to the server using an asynchronous request. If you're
familiar with 
Flickr - I imagine it to work like editing photo titles.

WDYT?

-- Andreas


-- 
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

On 3/21/08, Andreas Hartmann <andreasapache.org> wrote:
>  everytime the meta data tab is requested, a
continuation is created.
>  Even if you modify and save the meta data, another
continuation is
>  created, because the screen is displayed again. This
behaviour
>  unnecessarily increases memory consumption.
>
>  I see two options to avoid the problem:
>  1. Don't create continuations
>  2. Separate "modify meta-data" usecase
>
>  The major problem with approach 1. is that it doesn't
detect read-write
>  conflicts - with concurrent modification, the second
commit overrides
>  the changes of the first one. This is especially
problematic with our
>  current approach: All meta data values are saved, not
only the modified
>  ones.
>
>  Approach 2. requires additional clicks, but I think we
could live with that.
>
>  How about this approach: The meta data screen has no
submit button by
>  default, but next to each (editable) field is an
"Edit" button. When you
>  click it, an optimistic usecase is started, which only
manipulates this
>  single field. The "Edit" button changes to
"Save". The changes are sent
>  to the server using an asynchronous request. If you're
familiar with
>  Flickr - I imagine it to work like editing photo
titles.
>
>  WDYT?
>  -- Andreas


My vote would be for #1 because I have psychoses about
locking systems
and limited-duration server-based data storage.

If using #2, do not add clicks.  AJAX needs neither the
submit button
nor "edit" links.  Just use onChange() and similar
events to trigger
the sendInformation().  Even a monitor thread checking every
5 seconds
to test for changed fields is better than adding clicks.  (I
also have
a psychosis about creating listener threads for trigger
events.)

solprovider

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

On 3/22/08, Andreas Hartmann <andreasapache.org> wrote:
> solproviderapache.org schrieb:
> > On 3/21/08, Andreas Hartmann <andreasapache.org> wrote:
>  >>  everytime the meta data tab is requested, a
continuation is created.
>  >>  Even if you modify and save the meta data,
another continuation is
>  >>  created, because the screen is displayed
again. This behaviour
>  >>  unnecessarily increases memory consumption.
>  >>
>  >>  I see two options to avoid the problem:
>  >>  1. Don't create continuations
>  >>  2. Separate "modify meta-data"
usecase
>  > My vote would be for #1 because I have psychoses
about locking systems
>  > and limited-duration server-based data storage.
> If we submit only a single value (e.g. using AJAX or by
comparing old
>  and new values), #1 might be OK. Mabye we could send
the original value
>  together with the new value so that the server can
check for concurrent
>  changes and output a warning (avoid read-write
conflicts) without
>  server-side locking.
>  > If using #2, do not add clicks.  AJAX needs
neither the submit button
>  > nor "edit" links.  Just use onChange()
and similar events to trigger
>  > the sendInformation().
> Won't that generate a lot of traffic? Or is it easy to
add a timer which
>  submits only if no change happened e.g. for 1 second?
Personally, I
>  don't mind to add at least a "Save" button.
Hitting the return key
>  should also work.

Normal overhead is one POST request containing all fields. 
AJAX
overhead is a POST request containing one field and its old
value for
each change.

Sending each field when changed (and only the field that has
changed)
may reduce traffic compared to submitting the entire page
depending on
user behavior and the data.  A user editing each field three
times
would save bandwidth by submitting everything once when
finished.  A
user changing only three of twenty fields and editing each
field only
once would save bandwidth by sending the individual fields.

Bandwidth is a minor consideration.  This discussion is
about patching
communication methods to overcome the limitations of the
model.
Function before performance.  Besides, metadata is edited
so
infrequently that performance only matters when the server
is
corrupted (like the multiple-continuations memory leak you
are trying
to solve.)

>  > Even a monitor thread checking every 5 seconds
>  > to test for changed fields is better than adding
clicks.  (I also have
>  > a psychosis about creating listener threads for
trigger events.)
> I don't quite understand the bit about the listener
threads - would you
>  mind elaborating? Thanks a lot!

Sorry, my mistake.  My last sentence should have been
"...about using
monitor threads to handle triggered events" like having
a schedule
checking for changed fields (= monitor thread) when the
action
changing the field should trigger the event.

---
Here is a demonstration:
http://solpr
ovider.net/fieldupdates.html

HTH,
solprovider

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org