Hi,
just added a first version of an userAdmin command [1] ... usage:
userAdmin copyData <source-uri> <target-uri>
where source- or target-uri can be something like: file://<filename> or
userAdmin://<bundle-symbolic-name>
The first one reads/writes XML data - the second one uses the UserAdmin
service provided by the given bundle.
The command is currently implemented as command for the Felix-Shell - do we
need to support more shells? Btw: what's the status of the Pax-Shell?
Cheers,
Matthias
On Sun, Aug 2, 2009 at 3:01 AM, David Leangen <op...@leangen.net> wrote:
>
> On Aug 1, 2009, at 7:18 PM, Matthias Küspert wrote:
>
> On Sat, Aug 1, 2009 at 3:44 AM, David Leangen <op...@leangen.net> wrote:
>>>
>>> Sure, this could be done at the data level. Or, you could have some kind
>>> of export interface that people need to implement (so just the general case
>>> of the tool above). This could provide even more flexibility, for example in
>>> the case of people who have data stored remotely.
>>>
>>> Example:
>>>
>>> public interface UserDataExporter
>>> {
>>> Collection<String> getAllUserIds();
>>> User getUser( String id );
>>> }
>>>
>>> The person would be responsible for creating a bundle the implements this
>>> interface, hooking up to their impl and creating a User Object from their
>>> data. The import tool would suck up the current data via this tool just like
>>> for the tool above.
>>>
>>
>> That's an interesting idea ... thinking along this path: then the exporter
>> interface must have methods for all the data-getters in the UserAdmin:
>> getMembers(), getProperties(), getCredentials(), etc. I would also suggest
>> that the exporter interface(s) should only have basic types like String as
>> return type, so the developer of the exporter implementation does not have
>> to implement unnecessary methods from the UserAdmin interfaces (e.g:
>> addMember(), ....)
>>
>> WDYT?
>>
>
> Indeed, you'd want to provide ways to suck up all the relevant data. You're
> right that it would be better to provide an environment where people don't
> have to implement unnecessary stuff. Another approach could be to provide an
> abstract base class for User and such, and users only need to implement
> simple methods that provide String values, like you suggest.
>
>
>
> Cheers,
> =David
>
>
>
> _______________________________________________
> general mailing list
> general@lists.ops4j.org
> http://lists.ops4j.org/mailman/listinfo/general
>
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
