I think this is due to the push to SRM V2 after very little experience
of SRM V1 while SRM V3 has never caught the mind of the commissioners
who assumed that SRM V3 was a low priority and so did not encourage work
on SRM V3. This is not their fault.
Unfortunately the development teams tend to be required to focus on
support and development rather than focusing on standardisation before
development this is wrong with SOA development in my opinion. I think
its a clear case of a general and institutional (I am not guilt free
here) misunderstanding on how writing service orientated systems
requires considerable effort in designing the API up front. Many people
have claimed their is no demand for SRM V3 so we don't need to improve
the specification, many people have claimed that SRM specification
development like writing papers is a job you do after you finish your
day job. No this is what you do to save money later in the life cycle of
development.
Resolving ambiguities, tightening the specification and clearly drawing
up feature comparison matrices are all things that should have been done
to provide a solid and better specification. I believe having the
specification of a SOA complete is a requirement before DPM/Castor 2
where commissioned.
This is clear form the SRM V1 experiences and one of the reasons I did
not believe the REQUIREMENT to move my work to support SRM V2 was
realistic considering the other requirements on my time such as support
and release management.Unfortunately life is not Utopian.
Regards
Owen
PS
in this area we just need to make everything work for 2007 and we are
making great strides but are still tight on time and resources for this
to work so lets try and be positive and put more effort into documenting
testing and regression testing the API in the way Jiri is now having to
do (hence he has now seen most of the issues in the API)
On Thu, 2 Feb 2006 08:44:19 +0000
Jiri Mencak <[log in to unmask]> wrote:
> Hi Greig,
> nice to see somebody read the report, thanks!
>
> Words written by `Greig A Cowan' on 01 Feb 2006 at 22:09:55 +0000
> prompted:
> > Any word from the developers about if/when the unsupported
> > functionality will be supported?
> I'm in contact with them. I honestly doubt that the full SRMv2
> functionality will ever be supported by an SRMv2 server.
>
> > Or are these the optional bits of the API that don't have to be
> > implemented?
> <rant>
> SRMv2 specification is a mess. If anyone points me at some
> proper SRMv2 documentation, I'll be happy to figure out the answer ;).
> Unfortunately, no proper documentation exists, and the "specification"
> is full of ambiguities open to interpretation.
> </rant>
> I can only assume that *all* SRMv2 functions are compulsory. It is
> only certain fields in SRMv2 requests which are optional. On the
> other hand, the main SRMv2 developers I know are converging on an
> agreement as to which functions should be supported, mainly based
> on the assumed usefulness of the functions by the experiments and
> the fact of how difficult their implementation is. They are more
> or less "cleaning" the specification up by implementing it. I can
> only agree with Owen: every specification should have a reference
> implementation... This didn't not happen with SRMv2. Anyway, there
> are also other concerns like recursive srmLs being effectively a DoS
> on an SRMv2 server, so some developers decided not to implement it.
>
> To summarize, I'm sad to said there is no standard, just a couple of
> converging implementations.
>
> HTH.
>
> --
> Jiri
>
> >
> > Cheers,
> > Greig
> >
> > On Wed, 1 Feb 2006, Jiri Mencak wrote:
> >
> > > Dear all,
> > > as promised, I have some preliminary results of the DPM's SRMv2
> > > tests. If you're interested, please take a look at
> > >
> > > https://wiki.gridpp.ac.uk/wiki/DPM_SRMv2_Status
> > >
> > > The DPM's author was contacted, SRMv2 daemon crashes I've
> > > experienced were promised to be fixed in DPM 1.4.6 (not tested
> > > yet).
> > >
> > > A preview of the client I've done the testing with should be ready
> > > by the end of this week.
> > >
> > > Regards.
> > >
> > >
> >
> > --
> > ===================================================================
> > ===== Dr Greig A Cowan
> > http://www.ph.ed.ac.uk/~gcowan1
> > School of Physics, University of Edinburgh, James Clerk Maxwell
> > Building
> >
> > TIER-2 STORAGE SUPPORT PAGES:
> > http://wiki.gridpp.ac.uk/wiki/Grid_Storage
> > ===================================================================
> > =====
>
> --
> Jiri
|
