September 2007 - saga-rg

Re: [SAGA-RG] URL class in SAGA?
by Andre Merzky 19 Sep '07

19 Sep '07

Well, we should not change the spec just because some Java class is broken, and some other not ;-) The question of replacing URLs with URIs came up, however, mainly for the reason that URIs would allow unicode characters in file names etc. That would on the other hand break compatibility with other OGF standards, where filenames are expressed as URLs, not URIs. Anyway, that indeed is still an open point. Cheers, Andre. Quoting [Rob van Nieuwpoort] (Sep 19 2007): > > Hi, > > In JavaGAT, we use URIs, not URLs... As far as I know, Java URIs do not > suffer from any of the problems that Jon mentioned. > Maybe that is a good idea for SAGA as well? > > Cheers, > > Rob > > Andre Merzky wrote: > >Cools features indeed... > > > >As far as I know, Rob did a couple of fixes to the Java URL > >class for the JavaGAT - I guess they dealt with those kinds > >of problems, and, IIRC, also fixed the parsing of > >absolute/relative paths (http://host/dir/file vs. > >http://host//dir/file) > > > >Anyway, as you say, thats something which can be done within > >the implementation - the URL class would still be useful to > >get the data from application space, and to do parsing and > >some sanity checks. So, it would not solve problems, but > >simplify the application code. > > > >Andre. > > > > > >Quoting [Jon MacLaren] (Aug 30 2007): > >>Cc: SAGA RG <saga-rg(a)ogf.org>, Ceriel Jacobs <ceriel(a)cs.vu.nl>, > >> Rob van Nieuwpoort <rob(a)cs.vu.nl>, > >> Hartmut Kaiser <hartmut.kaiser(a)gmail.com>, > >> Ole Christian Weidner <oweidner(a)cct.lsu.edu> > >>From: Jon MacLaren <maclaren(a)cct.lsu.edu> > >>Subject: Re: [SAGA-RG] URL class in SAGA? > >>To: Andre Merzky <andre(a)merzky.net> > >> > >>But there are problems with the Java URL Class - it has some very odd > >>behavior. > >> > >>When you create a URL, there is an attempt to lookup the host name. > >>Two URL objects created from the same identical address, e.g. > >> > >> https://scoop.cct.lsu.edu:9877/ocracoke > >> > >>...but at different times (e.g. once when the host could not be > >>looked up, once when it could) can produce different hash values. So > >>if you use these objects as keys in a HashMap, they can sometimes > >>fail to lookup properly. > >> > >>Worse, when invoking equals on two URLs, host lookups are again > >>resolved. If your DNS server is down, the comparison can hang - this > >>depends on the underlying OS's behavior. On Linux this used to hang > >>indefinitely until the server came back! > >> > >>I've discovered these features over a period of a couple of years. > >>They are horrible. > >> > >>You should seriously consider using strings in an underlying Java > >>implementation - maybe creating a URL object just to do the format > >>checking, then throwing it away. > >> > >>Another nice feature, is that Java, by default, will cache DNS > >>lookups forever, i.e. until the application finishes. If this is a > >>Tomcat container, then you won't see legitimate DNS changes until the > >>container is restarted. That could be months at a time. To change > >>that, you have to edit java.security - which is a machine-wide change > >>for all applications. > >> > >>Nice. > >> > >>Jon. > >> > >> > >>On Aug 29, 2007, at 7:41 PM, Andre Merzky wrote: > >> > >>>I seem to remember that the topic of an URL class was, once > >>>upon a time, discussed by the group, but I can't find any > >>>notes nor mails about it. > >>> > >>>>From what I remember, the consensus was that several > >>>languages do have a native URL/URI class (e.g. Java), and > >>>that then the language bindings should allow to use these > >>>classes instead or additionally to strings. > >>> > >>>However, Ole and Hartmut argued that the C++ bindings should > >>>have an URL class, too, as the task of generating and > >>>parsing teh URLs would be left as a tedious excercise to the > >>>end user. > >>> > >>>Now, if we are going to specify URL classes for basically > >>>all bindings, then we may as well consider to use a simple > >>>URL class in the spec. OTOH, that might be overkill, and > >>>the bindings may be just the right place to deal with that > >>>topic. > >>> > >>>As I am blessed with a very poor memory, I really can't > >>>remember if that was discussed already, or if I for example > >>>was opposed to an URL class myself :-P Anyway, I'd like to > >>>raise the question (again), and would love to hear your > >>>opinions. > >>> > >>>Thanks, Andre. > >>> > >>> > >>>PS.: _if_ we would include an URL class in the spec, I'd > >>>insist on keeping it as simple and small as possible. No > >>>need for fancyness here - setters and getters for the URL > >>>elements is all what we basically need, right? > >>> > >>>-- > >>>"XML is like violence: if it does not help, use more." > >>> > >>>-- > >>> saga-rg mailing list > >>> saga-rg(a)ogf.org > >>> http://www.ogf.org/mailman/listinfo/saga-rg > >>> > > > > > > -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

1 0

Re: [SAGA-RG] Final call: task model...
by 'Andre Merzky' 18 Sep '07

18 Sep '07

Hi, Quoting [Ceriel Jacobs] (Sep 18 2007): > > Quoting [Hartmut Kaiser]: > > > > Leaves us with the question if this is implementable in other languages as > > well, such as C, FORTRAN or scripting languages. I'm not sure if that's > > possible. Especially scripting languages often rely on runtime polymorphism, > > not compile time polymorphism. Wouldn't it be better to leave the templated > > interface as an implementation detail and just to require to store the > > result inside the task? As I said - I'm not sure. > > I agree with this. It is an implementation detail. It is up to the > implementation to provide a mechanism for obtaining the result from the task, > and give an exception if this is attempted while the task is not finished yet. > > If the specification language used for SAGA allows for templates, > I would suggest to use them, but to specify that an implementation is allowed > to use runtime polymorphism instead. Yep, I agree, too - sorry for not beeing precise (i.e. language agnostic) enough. Thats certainly a language binding issue - important is to store the result in the task, and to be able to retrieve it after the task finishes. BTW, we still have a number of calls which have either additional out, or inout, parameters. For those, the described mechanism would not apply. Do you see that as a problem? If yes, the only (?) solution would be to add more getters for the other out/inout parameters as well. Cheers, Andre. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

1 0

Final call: task model...
by Andre Merzky 18 Sep '07

18 Sep '07

Hi Folx, Well, the final calls for the SAGA task model are resembling several of the more long running TV soaps by now: there always seems to be another season coming... Anyway, triggered by a comment from Ceriel, we discussed a change to the task model at last OGF, agreed upon accepting it, and this is, as said, the final call for that change. The proposal is as follows: the original task model resulted in the following code (C++): ------------------------------------------------------------ std::size_t len_in = 11; std::char data[12] = "hello world"; std::ssize_t len_out; saga::file f (url); saga::task t = f.read <saga::task::Async> (buffer (data, len_in), &len_out); // some time later, in a different code section t.wait (); std::cout << "read " << len_out << " bytes" << std::endl; ------------------------------------------------------------ That would change to: ------------------------------------------------------------ std::size_t len_in = 11; std::char data[12] = "hello world"; saga::file f (url); saga::task t = f.read <saga::task::Async> (buffer (data, len_in)); // some time later, in a different code section std::ssize_t len_out = t.get_result <std::ssize_t> (); std::cout << "read " << len_out << " bytes" << std::endl; ------------------------------------------------------------ change: - task gets a templatized member function get_result(), which returns the return value of the async funtion after the task gets completed. Calling get_result() implies a wait(). PROs: - no need to carry the return value from task creation to where it is getting used. - no possibility to access the uninitialized return value - sync and async calls have _exactly_ the same signature now, and only differ in their return values. CON: - adding templates for member functions in application space. As a side note: earlier in the evolution of the spec, we dropped the following mechanism: ------------------------------------------------------------ saga::task t = f.seek <saga::task::Async> (where, whence)); // some time later, in a different code section t.wait(); saga::file f2 = (saga::file) t.get_object (); f2.read (...); ------------------------------------------------------------ which allowed to get the originall calling object back from a task, and thus eliminating the need for the application to keep track of task/object relations. That was removed because of the cast implied, and a UUID was added instead to simplify the application level book keeping. However, we could, with the same mechanism, add a type safe get_object again, with no penalty: ------------------------------------------------------------ saga::task t = f.seek <saga::task::Async> (where, whence)); // some time later, in a different code section t.wait(); saga::file f2 = t.get_object <saga::file> (); f2.read (...); ------------------------------------------------------------ which would eliminate (or at least minimize) the need for application level book keeping. Opinions would be very welcome, otherwise the spec gets updated as decided at the last meeting. Thanks, Andre. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

3 2

URL class in SAGA?
by Andre Merzky 18 Sep '07

18 Sep '07

I seem to remember that the topic of an URL class was, once upon a time, discussed by the group, but I can't find any notes nor mails about it. From what I remember, the consensus was that several languages do have a native URL/URI class (e.g. Java), and that then the language bindings should allow to use these classes instead or additionally to strings. However, Ole and Hartmut argued that the C++ bindings should have an URL class, too, as the task of generating and parsing teh URLs would be left as a tedious excercise to the end user. Now, if we are going to specify URL classes for basically all bindings, then we may as well consider to use a simple URL class in the spec. OTOH, that might be overkill, and the bindings may be just the right place to deal with that topic. As I am blessed with a very poor memory, I really can't remember if that was discussed already, or if I for example was opposed to an URL class myself :-P Anyway, I'd like to raise the question (again), and would love to hear your opinions. Thanks, Andre. PS.: _if_ we would include an URL class in the spec, I'd insist on keeping it as simple and small as possible. No need for fancyness here - setters and getters for the URL elements is all what we basically need, right? -- "XML is like violence: if it does not help, use more."

2 2

Fwd: [global-custreqs] Groups - OASIS: 6 New Committees Standardizing SCA for SOA (SCA OASIS - 6 SOA TCs .pdf) uploaded
by Craig Lee 11 Sep '07

11 Sep '07

All, The OSOA work (www.osoa.org) is now being sent through the OASIS standardization process. The OSOA approach is SCA (Service Component Architecture) and SDO (Service Data Objects) which seems to me like it makes services and data independently manageable, a la WSRF. WRT framework, policy, bindings, I wonder how much they are reinventing? WRT the C/C++/Java use in SCA domains, I wonder how much SAGA could do this right now? --Craig >Delivered-To: lee(a)aero.org >Mailing-List: contact global-custreqs-help(a)lists.ncoic.org; run by ezmlm >X-No-Archive: yes >List-Post: <mailto:global-custreqs@lists.ncoic.org> >List-Help: <mailto:global-custreqs-help@lists.ncoic.org> >List-Unsubscribe: <mailto:global-custreqs-unsubscribe@lists.ncoic.org> >List-Subscribe: <mailto:global-custreqs-subscribe@lists.ncoic.org> >Delivered-To: mailing list global-custreqs(a)lists.ncoic.org >Date: 10 Sep 2007 12:46:45 -0700 >To: global-custreqs(a)lists.ncoic.org >From: "Steve Russell" <Steve.Russell(a)l-3com.com> >Subject: [global-custreqs] Groups - OASIS: 6 New Committees Standardizing >SCA for SOA (SCA OASIS - 6 SOA TCs .pdf) uploaded >Sender: global-custreqs-return-782-lee=aero.org(a)lists.ncoic.org >X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on > rushe.aero.org >X-Spam-Level: >X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham > version=2.60 > >Six OASIS Technical Committees formed for developing NIF-like Service >components, specifications, and developer guidance. > > -- Steve Russell > >The document named OASIS: 6 New Committees Standardizing SCA for SOA (SCA >OASIS - 6 SOA TCs .pdf) has been submitted by Steve Russell to the >Requirements Validation FT document repository. > >Document Description: >OASIS, the international open standards consortium, has formed 6 new >technical committees to simplify SOA application development by advancing >the Service Component Architecture (SCA) family of specifications. The >work will be organized within the OASIS Open Composite Services >Architecture (Open CSA) Member Section, and the resulting specifications >will be offered for implementation on a royalty-free basis. The six new >Technical Committees (TCs) and their roles are: > >1. SCA-Assembly: define core framework. >2. SCA-Policy: define policy framework and specific policies. >3. SCA-Bindings: define bindings for SCA services and technologies. >4. SCA-BPEL: define how to write SCA component implementations. >5. SCA-C-C++: develop specs that standardize C and C++ use in SCA. >6. SCA-J: develop specs that standardize Java use in an SCA domain. > >View Document Details: >https://www.ncoic.org/apps/org/workgroup/custreq/document.php?document_id=6… > >Download Latest Revision of Document: >https://www.ncoic.org/apps/org/workgroup/custreq/download.php/6733/latest/S… > > >PLEASE NOTE: If the above links do not work for you, your email application >may be breaking the link into two pieces. You may be able to copy and paste >the entire link address into the address field of your web browser. > >-Network Centric Operations Industry Consortium Administration > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: global-custreqs-unsubscribe(a)lists.ncoic.org >For additional commands, e-mail: global-custreqs-help(a)lists.ncoic.org

2 1